Re: [widgets] Widgets URI scheme... it's baaaack!

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