gmane.org.w3c.appformats

Re: [widgets] Content-type sniffing and file extension to MIME mapping

Jonas Sicking — 2008-12-02T01:05:08

Marcos Caceres wrote: I'm mostly in the same boat :) But it does look like .flac is the preferred extension. / Jonas

Re: [widgets] Content-type sniffing and file extension to MIME mapping

Marcos Caceres — 2008-12-02T00:42:21

On Tue, Dec 2, 2008 at 12:22 AM, Jonas Sicking sicking.cc> wrote: Ok, sounds good. I suppose flac has a .flac extension? (sorry, apart from mp3 and wav, I don't know audio formats at all!)

Re: [widgets] Content-type sniffing and file extension to MIME mapping

Jonas Sicking — 2008-12-02T00:22:25

Marcos Caceres wrote: I'd stick with wav for now. Possibly also FLAC. / Jonas

Re: [widgets] Content-type sniffing and file extension to MIME mapping

Marcos Caceres — 2008-12-02T00:12:14

On Mon, Dec 1, 2008 at 11:48 PM, Jonas Sicking sicking.cc> wrote: Ok, no MP3. maybe you can suggest some other suitable audio format?

RE: ZIP-based packages and URI references into them ODF proposal

Larry Masinter — 2008-12-01T23:57:29

Hi Ian, I think this is an interesting and important discussion, but I realize that we've moved from discussing ZIP packages and URI references into them to a deeper discussion of the role of architecture and orthogonality, language specifications vs. implementation guidelines, the handling of error conditions in standards documents, and the interplay of extensibility vs. consistency of behavior. I think that's important, but perhaps should be handled with a narrower mailing list: I'll respond on www-tag. Larry

Re: [widgets] Content-type sniffing and file extension to MIME mapping

timeless — 2008-12-01T23:47:56

On Tue, Dec 2, 2008 at 1:42 AM, Marcos Caceres gmail.com> wrote: you're missing .jpg which is fairly odd.

Re: [widgets] Content-type sniffing and file extension to MIME mapping

Jonas Sicking — 2008-12-01T23:48:42

Marcos Caceres wrote: I'm not a big fan of "endorsing" mp3 given that it's a patented format that can't be implemented by FOSS software. / Jonas

Re: [widgets] Content-type sniffing and file extension to MIME mapping

Marcos Caceres — 2008-12-01T23:42:25

Ok, hearing no objections, then I propose we bake in the following file extensions into the spec (we can debate which MIME types to use after we settle on the extensions!): .html .htm .css .gif .jpeg .png .js .json .xml .txt The following we should probably bake in too: .mp3 .swf .wav .svg .ico We may bake in the following: xhtml Please suggest more you would like to see! Kind regards, Marcos

[widgets] Agenda for 4 December 2009 Voice Conference - NOTE NEW TIME!

Arthur Barstow — 2008-12-01T20:40:12

Below is the draft agenda for the November 20 Widgets Voice Conference (VC). Two notes on this agenda: 1. NOTE the TIME CHANGE! 2. It is highly unlikely we will cover the Widgets DigSig spec or the API and Events spec. Please review the related ACTIONs and respond accordingly. Inputs and discussion on the agenda topics before the meeting is encouraged. Logistics: Time: 24:00 Tokyo; 17:00 Helsinki; 16:00 Paris; 15:00 London; 10:00 Boston; 07:00 Seattle Duration = 60 minutes Zakim Bridge +1.617.761.6200, conference 9231 ("WAF1") IRC channel = #wam; irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements a. December VC schedule: December 18 is the next and last VC of the year 3. P&C spec: NOTE - BEFORE the VC, please review Section 1-7 and submit any comments to public-webapps: a. File extension to Media-type - see discussion thread "Content-type sniffing and file extension to MIME

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Marcos Caceres — 2008-12-01T20:13:16

Hi Dan, On Mon, Dec 1, 2008 at 6:20 PM, Dan Brickley danbri.org> wrote: It sure does. But, and this is a big *but*, XHTML support is purely OPTIONAL. However, authors can certainly do the following: I like this, but I think this should be the default (always on). I think we should introduce the override in Widgets version 2. Yeah. I did a search for this too... no luck. Would be helpful. This is getting a bit too fancy I think. This would require that all widgets be written this way. Seems very labor intensive to have to specify the content for every resource one references. I think it would also be more prone to errors, as it puts the burden on authors to identify the content types. For references that dereference locally (i.e., not HTTP, but widget:// or whatever scheme we end up with), it would be better to have the widget engine resolve the type via the file extension or sniffing. Like I said, today's widget engines wor

Re: [WebIDL] Java package mapping

Cameron McCormack — 2008-12-01T19:30:17

Kartikaya Gupta: Thanks, fixed. Indeed, that’s part of why I’ve held off updating the grammar. I plan to change the grammar to parse any balanced content between commas in square brackets as an ExtendedAttribute, and to then have rules like: ExtendedAttributeScopedName → identifier "=" ScopedName along with a statement “if it matches ExtendedAttributeScopedName, then the extended argument takes a ScopedName”. This would happen to make some extended attributes be more than one of these types (like the single identifier matching both the ScopedName and identifier argument forms), but I wouldn’t have any extended attributes defined that could take both. The above would then allow me to say that any other balanced sequence of tokens that was found between commas is some extension that can be ignored. (Where by “balanced” I mean balanced brackets, quotes, etc., which should cover most cases that people would want to do in their own extended attributes.)

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Dan Brickley — 2008-12-01T18:20:29

Marcos Caceres wrote: Really? So we are clear here .... does the widgets spec allow to point to an XHTML document that begins with something like ...? (see design 4 below) some strawpeople: 1. simple. It basically means, "if this is set to true, the filenames you'll find in this zip correspond to (some / latest) version of IANA, at time of widget zip creation. Would need some rules re precedence/ordering. 2. (except i can't find a single URI for versions of their registry) 3. allows to be more explicit about which version of the IANA registry 4. An

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Marcos Caceres — 2008-12-01T18:15:23

Hi Stuart, On Mon, Dec 1, 2008 at 4:37 PM, Williams, Stuart (HP Labs, Bristol) hp.com> wrote: Agreed. But you get the same problem with mislabeled types in HTTP. In the majority of cases the file extension will be correct. It would be overly prescriptive for us to have the solution in the requirement. The requirement basically boils down to: relative and absolute addressing (in the path-sense). This requirement is just concerned with having a path (not a full URI scheme). Yes. Addressing scheme does not mean URI Scheme in R6. It means what you said ( "approach for addressing widget components"). In other words, some general way to simply identify a file inside the package. Ok. I'm honestly not being stuburn about this, I simply don't understand how [1,1a] or [2] works. Also, other members of Web Apps don't understand how it works. This is why we came to the TAG for guidance. No no no! I'm not rejecting any input. Honestly, I didn't mean to sound like I was. I'm sorry you interpreted my comm

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Marcos Caceres — 2008-12-01T17:39:25

On Mon, Dec 1, 2008 at 5:31 PM, Dan Brickley danbri.org> wrote: right :) So we are clear, what do you have in mind here? Kind regards, Marcos

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Dan Brickley — 2008-12-01T17:31:31

Williams, Stuart (HP Labs, Bristol) wrote: (Just allow RDFa+XHTML and leave it to the marketplace...) So this seems like a very small piece of metadata ('this filetree follows the IANA filename to media type mappings') has a lot of value. If the versions of the IANA mapping are easily identified, the metadata becomes a URI rather than a single bit. Either way, you can gain a lot from not a lot, I think. cheers, Dan -- http://danbri.org/

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

John Kemp — 2008-12-01T17:10:00

Stuart, ext Williams, Stuart (HP Labs, Bristol) wrote: ... Indeed. Of course the metadata could still also be present inside the zip file in addition to being linked via the HTTP Link header. Cheers, - johnk

RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Williams, Stuart (HP Labs, Bristol — 2008-12-01T16:48:09

Hello John, In principle that's a possibility - though it provides an opportunity for more failure modes (got the package, failed to get it's metadata) - and there will be the inevitable multiple round-trip concerns, though since the headers before the body metadata retrieval could be concurrent. Plausible, though I have not looked at Atom in detail. Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Williams, Stuart (HP Labs, Bristol — 2008-12-01T16:41:02

Hello Art, Surely that is a bit subjective. Folks creating widget packages are going to be tech savvy users and probably using tools that automate the process. Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Williams, Stuart (HP Labs, Bristol — 2008-12-01T16:37:38

Your or your WG's call. What is registered (RFC 4288 section 4.11) is a list of file name extensions commonly used with the media-type. It does *not* reserve the extension for exclusive use with that media-type. It does *not* prevent other arbitrary file name extension or indeed no-extension being used. So... yes not a bad hint, but nothing is certain. Not with certainty... Which part of http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing says that? I do not see that stated as a requirement there. Ok... so I now think that we are speaking at cross purposes. I read 'widget-reqs/#r6.-addressing" as stating requirements for a widget addressing scheme. I take the use of the word 'scheme' in that requirement as very general - ie. I do not specifically read it as "URI Scheme", but as "approach for addressing widget components". If by the use of the word "Scheme" in "Addressing Scheme" means "URI Scheme" which your response seems to suggest then I think that you have already made the wrong choice o

Re: [WebIDL] Java package mapping

Kartikaya Gupta — 2008-12-01T16:18:10

On Mon, 1 Dec 2008 11:12:13 +1100, Cameron McCormack mcc.id.au> wrote: The example in the java-modules section has a typo; it says "org.foo.ext.FooDocument" instead of "org.foo.ext.ExtendedFooDocument". Also, I'm not sure if this matters, but while implementing I realized that having both [TheExtendedAttribute=identifier] and [TheExtendedAttribute=ScopedName] leads to an ambiguous grammar, since [foo=bar] can be interpreted as both. Presumably this would lead to shift-reduce conflicts with a context-free parser generator. For my implementation I always resolve it to be a ScopedName and then use either the prefixed name or the unprefixed name depending on which attribute it is. Cheers, kats

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

timeless — 2008-12-01T15:40:50

On Mon, Dec 1, 2008 at 5:35 PM, John Kemp nokia.com> wrote: no. it is not the case. a widget is a widget in its own right, there may or often may not be a similar object available from an http/https resource.