Re: MIME types for packaged content (was re: tag: uri scheme)

Hi Larry,
Apologies for not responding sooner.
2009/2/13 Larry Masinter <masinter@adobe.com>:
> I think it would be much better to allow content types to be
> derived by the packager and included in the package on
> a file-by-file basis. This was the finding during the
> development of MHTML many years ago, and the situation
> isn't different here.
>

Personally, I'm not a big fan of having to get a packager to inspect
all the media types to derive a manifest every time I build a package
(I think if there is going to be a media type sniffer then it should
just be built into the widget engine and should have standardized
behavior... whatever that may be). I also see having a 1 to 1 mapping
between file and media types in a separate metadata definition/file as
fragile because they can easily fall out of sync. As an author, I
should not have to rely on packaging tool for creating widgets. This
is an explicit design goal for Widgets [2] (see 'ease of use'). For
this reason, I proposed just using a MIME to file extension mapping
mechanism, which is loosely based on Apache.

So, given your feedback, and the feedback of others, I've recently put
together a proposal for how we might address this [1]. Web Apps is
hoping you could find the time to review and comment on the proposal
above.

So people don't need to go to [1], the proposed solutions looks
something like this:

<widget xmlns="..." >
   <media ext='php' type='application/html+xml' />
</widget>

> There are several operating systems in wide use today
> which allow files without extensions to be "sniffed"
> on the client. This would also allow the inclusion
> of charset parameters in text types, which, in general,
> cannot always be easily "sniffed", even if they are
> well known in the context of the packager.

For the second part of the proposal [1], I said we should have something like:

<file path="/some/path.file" type="some/type" charset="name" />

It might be that we end up supporting both <file> and <media> or we
somehow glue them together into a single tag... something like:

Usage 1, where charset is optional, but when used is applied to all
media of that type:
   <media ext='..' type='..' [charset=".."] />

Usage 2, where file is an absolute path to a file:
   <media file="/some/file" type='../..' [charset=".."]/>

Usage 3,
   <media file="/some/file" type='../..' [charset=".."]/>

Usage 4, where, for the sake of simplicity, the ext attribute is ignored:
   <media file="/some/file" ext=".." type='../..' [charset=".."]/>

> While I'm dubious about the arguments on "MIME type
> sniffing" for browsers, I think it's completely
> unnecessary for packaged content, because of the
> explicit "package" step necessary to provide
> conformant content.

I'm sorry, I'm not sure what you mean by conformant content? Can you
please explain? If you mean HTML, CSS, etc. files, our specification
does not put limits on the kind of content that can be included in a
package (we did do this in the past, but for architectural reasons we
took it out). One can now put any type of content in a package. No
validation is performed and user agents are free to support whatever
media types they wish. For example:

<widget xmlns="...">
   <content type="my.dll" type="x-whatever" />
</widget>

Kind regards,
Marcos

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0491.html
[2] http://dev.w3.org/2006/waf/widgets-reqs/#design-goals

-- 
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 22 February 2009 18:56:58 UTC