- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 15 Jun 2009 14:59:44 +0200
- To: Larry Masinter <masinter@adobe.com>
- Cc: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>, public-webapps WG <public-webapps@w3.org>, public-pkg-uri-scheme <public-pkg-uri-scheme@w3.org>
Hi Larry, On May 29, 2009, at 02:51 , Larry Masinter wrote: > I'd suggest looking harder at "thismessage", though, > before inventing a new URI scheme for "widget", > especially since it will (should) not appear outside > of the internal operational context. > > Reusing existing technology has the advantage of > learning from experience rather than repeating it. The WebApps WG fully understands the value of reusing existing technology over reinventing the wheel, and have attempted to do so throughout our deliverables. Before delving into deeper details I would like to point out that use cases have been brought forth concerning widget URIs appearing / outside/ their internal operational contexts — notably for inter- widget communication. Such use cases have however been pushed off to a future version of the widget family of specifications. The first thing that I would note concerning RFC 2557 is that it doesn't go very far in definition the thismessage: scheme. The latter is mentioned four times: that's not much to work with! I tried googling for more, but it doesn't appear to be a very popular discussion topic. In order to better contextualise this discussion, here are the four instances: I. (5.e) When the methods above do not yield an absolute URI, a base URL of "thismessage:/" MUST be employed. This base URL has been defined for the sole purpose of resolving relative references within a multipart/related structure when no other base URI is specified. II. (8.2.c) The result of this resolution can be an absolute URI, or an absolute URI with the base "thismessage:/" as specified in chapter 5. III. (8.2.d) This means that if one of the two URIs to be compared was a fictitious absolute URI with the base "thismessage:/", the other must also be such a fictitious absolute URI, and not resolvable to a real absolute URI. IV. (12) The handling of relative and absolute URIs for matching between body parts have been merged into a single description, by specifying that relative URIs, which cannot be resolved otherwise, should be handled as if they had been given the URL "thismessage:/". The first thing I can't wrap my head around here is whether relative URIs that cannot be resolved otherwise are given a *base* URL of "thismessage:/" which for a Content-Location of "foo/bar" would yield "thismessage:/foo/bar" as per (I), or if they are given a *URL* of "thismessage:/" in all cases as per (IV). Since (II) and (III) add essentially nothing ("it can be absolute, or absolute of this kind" and "they must be identical, so if one is fictitious the other is fictitious too"), and since (IV) probably intends to be a non-normative section (differences with 2110) we'll assume it is in error and go with (I) being the one true definition. I'll note that having to resort to exegesis through elimination does not fundamentally fill me with confidence when it comes to reusing a specification. The first thing we would have to do in our specification (we'd still need to publish something stating we're using thismessage:) is clarify this, after having co-ordinated with IETF to make sure we did indeed get it right. On to the next step: we don't have Content-Locations, our packages have an inherent structure based on Zip relative paths. So in order to reuse thismessage: we'd now have to define how to map a widget package onto a multipart/related message. Bringing in such MIME baggage isn't entirely reassuring either, but let us plod on. We declare that for each file entry in the package, a Content-Location is assigned to it that is its Zip relative path (or the same converted to a relative URI reference). That gets us close to what we want but not there yet: we also need to correctly map our L10N model. So taking as input the user agent's locale list, we first produce a simplified (L10N-free) view of the widget, then map that onto a multipart/related message so that thismessage: works. I think that this demonstrates that, technically speaking, reusing thismessage: *can* be done. That having been said, I am very much unconvinced that the cost/benefit analysis weighs in its favour. We would be reusing something that is not very far at all from being undefined, and is uncertain in its actual implemented deployment (is there a UA out there in which I can load a multipart/related message with unresolvable base URI, alert(document.location) and get "thismessage:/foo.html"?). We would furthermore be defining that through some form of Multipart Indirection Layer For Widgets that is likely to drag in someone else's gremlins. Furthermore, we're stuck with no authority component in the scheme should we wish to add one (I'd rather not speculate on the overhead involved in updating thismessage: to support an authority component). To summarise: the only thing we get from the reuse is a label, and we still have to define all of its processing and semantics. That's a very little benefit, and non-negligible costs. So my conclusion here is that while reuse is good, there is such a thing as reuse for reuse's sake. We're obviously fully open to other opinions, but for the time being we will stick to "widget:". PS: future messages on this topic will not be copied to public-pkg-uri- scheme as the use cases that we're addressing are at this stage separate from the packaging ones. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Received on Monday, 15 June 2009 13:00:21 UTC