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

> -----Original Message-----
> From: Marcos Caceres [mailto:marcosscaceres@gmail.com]
> Sent: 01 December 2008 15:28
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org; public-webapps
> Subject: Re: Sketch of an idea to address widget/package
> addressing with fragID syntax and media-type defn.
>
> Hi Stuart,
>
> On Mon, Dec 1, 2008 at 10:29 AM, Williams, Stuart (HP Labs, Bristol)
> <skw@hp.com> wrote:
> <snip>
> >>
> >> Unfortunately, widgets/zip do not maintain media-type information.
> >> That information is derived from content-type sniffing heuristics as
> >> defined in HTML5 [1].
> >
> > [Aside: Hmmm process wise that would create a dependency on
> > the publication of HTML 5 are you sure that you want to do that?]
> >
>
> Web Apps does not have a problem having a dependency on HTML5
> (particularly if the relevant section of HTML is proven to be stable
> by interoperable implementations). It might mean that Widgets sits on
> CR for 10 years, but that's ok with me at least. Sitting in CR for
> endless years didn't do any harm to CSS. However, if it does becomes a
> process problem for Web Apps, we might lift the relevant text out of
> HTML5 and put it in the Widgets spec.

Your or your WG's call.

> > Well there are ways around that, add a package description
> > or meta-data file either at the root of the package or at
> > each directory level and have it carry media-type information
> > - or use 'magic numbers' or (if you really must - in the
> > absense of other authoritative information), sniff/guess
> > though I think that should be the least preferred option.
> >
>
> Right. The new proposal is that we use file extension mappings to MIME
> types, and if that fails, result to sniffing. We are reluctant to
> introduce a meta-data format at this point. For version 2 of widgets,
> it might be useful to either introduce the meta-data format or  have
> an Apache-like file extensions to MIME type mapping. For example:
>
> image/gif .gif
>
> Note however, that widget engine in the wild have no problem working
> without MIME info. From what I have seen, they all do just fine either
> sniffing or using file extensions to derive the content types.
>
> > Anyway - that zip files don't intrinically maintain such
> > info is not a show stopper - though I would have thought that
> > carrying media-type information is a natural requirement for
> > a packaging format for the web.
> >
>
> I'm not sure it is. When a MIME type is registered with IANA, the file
> extension is also registered.

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.

> So one has a standardized way to derive
> the media type for a file by the file extension.

Not with certainty...

> So I guess it might
> make sense to have a table of common file extensions and related MIME
> types baked into the Widget spec for formats that the widget spec
> mandates support for (e.g., .html, .css, .js, .gif and so on).
>
> >> > Other characters than / and ! could be choosen as path and
> >> > container separators respective.
> >> >
> >> > Could this or something like it meet your requirements? If
> >> > not... which ones does it fail to meet?
> >> >
> >>
> >> Nice solution. But, unfortunately, widgets don't support inner
> >> packages (they inner packages are treated as arbitrary files) and we
> >> have no requirements that call for inner package access.
> >
> > Ok... but you answered a different question.
> >
> > I asked which of your requirements would an approach like this *fail* to meet?
> >
>
> ok, sorry. I should have answered that correctly:
>
> 1. The <path> part of the "scheme://<authority>/<path>/" does meet our
> requirements iff by <path> you mean path as defined in RFC2396 (with
> the ability to be an iPath as in RFC3987).

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.

> 2. the "scheme://<authority>/path" is the bit Web Apps really needs to
> sort out. I.e., what will we call the "scheme"?: widget:? zip:?
> package:? or something else? what will be the <authority>? will it be
> the package itself: zip://myZipfile.zip? or the widget engine
> zip://engine/someZip.zip/? and so on... do we need an authority at
> all? I think these, and probably about a dozen more questions, need to
> be addressed before we jump the gun and start solving secondary use
> cases (addressing inner inner packages)

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 of extension points.

I have said previously [1,1a] that I do not think that you need to define a URI scheme in order to meet your requirements... that the extension point in web architecture that you should be using is media-type and fragment identifier syntax. Whilst Larry[2] refers to a different extant MIME based approach - and you should consider that - he gives you good advice about the orthogonality of protocols, formats and identifiers. The reason that I made no proposal about "scheme://<authority>/path" is because what I was proposing was entirely orthogonal to that - it could work with just about anyURI scheme - certainly those that specify the hierarchical syntax and maybe some or all of those that don't.

> > I could paraphrase your response as:
> >
> >        "That would work, but it does more than we need."
> >
> > Dan Brickley's response[a] emphasised the need for nesting
> packages in packages. Even if that is not a capability that
> widgets would need to use, widgets could still share the same syntax.
> >
>
> Dan's problem may be a general problem, but I need to empathize that
> it's not a requirement in the widget world. We could live with a
> shared syntax, of course. However, what worries me is bloating the
> scheme with features that may be rarely used, expensive to implement,
> and introduce another attack vector.

Well, I and the TAG have expressed interest in that more general problem[3].
If you reject input on that basis you make it very hard for us to help you.
Maybe our help is not what you want.

> For those reasons alone, I would
> like us to develop the scheme to be as simple as humanly possible and
> meet the most fundamental use cases/requirements ([1], [2]) before
> anything else.
>
> > Anyway... I think that my sketch shows that there is a
> potential to develop a media-type + fragID-syntax based
> solution to the package component/widget addressing problem.
> >
>
> Completely agreed. But can we please work on the "scheme", "authority"
> and "path" bits first?

No... *we* cannot, because IMO you don't need to do that at all and it is predicate on the use of the wrong extension point in web architecture.

You can if you want to... but I think you are headed in the wrong direction.

> Kind regards,
> Marcos
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
> [1] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing
> [2] http://dev.w3.org/2006/waf/widgets-reqs/#r36.-

Regards

Stuart Williams
--
[1] http://lists.w3.org/Archives/Public/www-tag/2008May/0129.html
[1a] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0328.html
[2] http://www.w3.org/mid/8B62A039C620904E92F1233570534C9B0118B26017A2@nambx04.corp.adobe.com
[3] http://lists.w3.org/Archives/Public/www-tag/2008Jul/0006.html

Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 1 December 2008 16:41:41 UTC