RE: [widgets] Authorities will never have authority?

Robin,

In your message, you start to give a use case for how
the "authority" field might be used, namely that
the working group might have plans to introduce
inter-widget communication, and to use the authority
field, presumably in some way that would allow
inter-widget references.

I want to point out there's a serious problem with
IRIs and authority fields, and some pressure -- from
browser vendors! -- to treat the "authority" field as
a domain name in all cases, when translating from
Unicode -- and turn an IRI with unicode authority
into a URI by using punicode rather than percent
encoded UTF8 in hex as with the rest of the IRI.

So the webapps working group's intent to reserve
the authority field for use as identifying other
widgets to enable inter-widget communication might
have some problems, unless the intra-package
authority is always required to be US-ASCII. But
if you don't say what you're intending to use the
authority field for, how can we review it?

I will point out that the WebApps working
group charter

   http://www.w3.org/2008/webapps/charter/

only lasts until June 2010. So when you say
that at some point in the future "the working
group" intends to introduce inter-widget
communication supported by the authority
field, which working group are you presuming
would do that, when? 

As you are aware, I am sure, there are several
other zip-based packaging systems in use:

http://broadcast.oreilly.com/2009/01/packaging-formats-of-famous-ap.html

Should each invent their own URI schemes for
holding top-level of intra-package relative
references? Is the applicability of "widget"
and inter-package references restricted only
to W3C widgets? Would you want it to be
impossible to use the scheme to reference,
say, a resource within a JAR file?

Perhaps some of those other systems have a
different or similar mechanism? How can they
evaluate "widget:" for reuse if you don't
say how various parts of a widget URI will
be interpreted?

Or are those other committees allowed to define
a use for "authority" or "query" since the
W3C WebApps working group merely reserved them
for further use without any restrictions?

Or do you want to rule out convergence of
multiple zip-based packaging schemes in the
future?

Larry
--
http://larry.masinter.net


-----Original Message-----
From: Robin Berjon [mailto:robin@berjon.com] 
Sent: Tuesday, December 22, 2009 5:16 AM
To: Larry Masinter
Cc: Jonathan Rees; www-tag@w3.org
Subject: Re: [widgets] Authorities will never have authority?

Hi Larry,

well since we're on versioning, why not continue!

On Dec 22, 2009, at 03:48 , Larry Masinter wrote:
> The only value for authority that doesn't mean
> anything in future versions is to leave the authority
> out completely. It was pretty clear that previously, 
> the 'authority' component was planned for cross-package
> references, and taken out because of security concerns.
> 
> So I think if you want to "future proof" the possibility of
> including an 'authority' or 'query components' in widget:
> URIs, you could do something like
> 
> The URI syntax is
> 
>  "widget:/<path>"
> 
> but possibly note that future versions might add an
> authority component and a query component.
> 
> "Those who create widget URIs must not include an
> 'authority' or 'query' component. Those who validate
> URIs must reject, not match, treat as invalid,
> any URI which contains an authority or a query."

I beg to differ. The only way I see that one can future-proof the widget URI scheme is to define in exactly the way that it is defined in the current specification.

One aspect of URI schemes and other such compact representations is that they can't easily carry version indicators. Yet it is a fact that URI schemes do evolve over time, and therefore that we need a strategy to handle such evolution. I will posit that the strategy required here is rooted in "Language designers should strive to make their languages versionless at the syntax level." (from http://larry.masinter.net/tag-versioning.html).

Let us consider a very simple widget, comprised of a few pages that may be navigated. Each of those pages displays a navigation menu, on which the current page is marked differently from the others. In order to keep the widget manageable (pages may be added or removed over time) we have a script common to all pages that inserts the navigation menu and marks the link to the current page as special. Nothing magic, nothing contrived.

Now let's imagine that we adopt your proposal that v1 widget URIs MUST NOT produce an authority component.

In this scenario, the user agent therefore dutifully produces:

  widget:/dahut/left.html
  widget:/dahut/right.html
  widget:/dahut/milk.html
  widget:/dahut/and-unicorns.html
  widget:/dahut/against-chupacabras.html
  ...

I'm Joe Regular Web Hacker, and I need to write a script that tells me if the current page is the one I'm processing. Well that's dead simple! The condition I need is:

  document.location.href == myPage.href

Or perhaps I'm one of those people who always writes a library, just in case (not likely). Here's my library:

// you call this as var wuri = new WURIParser(yourWURI);
// and then use it as wuri.path
function WURIParser (wuri) {
    this.scheme = "widget";
    this.path = wuri.substring(7);
}

A little bit of time passes and the WG now wishes to proceed with its plans to introduce inter-widget communication - and naturally using the authority now seems like a great idea. Well - we've painted ourselves into a corner. We can't add it to our scheme as it'll break content (and I promise you that you can paint in fiery blinking letters that consumers should behave as if an authority component might be there, if it is mandated that it not be produced the majority of scripts will assume that it's not there). We can only either:

  a) find another way of expressing this capability. This is effectively identifying something without using a URI - wilful violation of AWWW here we come!
  b) mint a widget2 URI scheme which is 1) architecturally suboptimal and 2) make the WG grouchy because of the involved hurdles (not to mention that given the inflation of URI registration hurdles over the past ten years, who knows what act of contrition it may demand ten years hence?)

That isn't a satisfactory approach. Other options may not be perfect and pretty, but I don't think that it gets worse than being stuck at a version plus either identifying resources using something that isn't a URI or having to mint a second scheme for the exact same purpose just because we weren't forward looking.

The currently specified approach is in my opinion much better because it has a future-proof versionless syntax. This was deliberately designed into it after discussion with our community. The idea is that authority MAY be present, that it MUST be syntactically correct, that it is devoid of semantics but that since it is reserved for future use user agents ascribe behaviour or meaning to it at their own risk.

I think that the choice may come down to picking who to distrust most in their ability and willingness to follow a specification: a handful of user agent implementers eager to show that they pass a conformance suite or vast masses of scripting authors trying to use unfamiliar technology on a deadline. I know which side I'd rather bet on.

Obviously in an ideal world we'd just define what the authority means today, or wait until we can. But we don't have that ability now, and implementations of the widgets family are already shipping that need to put some URI identifiers on those resources.


Given that neither solving the problem now nor delaying are options, the WG is simply adopting the most future-proof and most reliable versioning strategy.

-- 
Robin Berjon - http://berjon.com/

Received on Saturday, 26 December 2009 23:23:23 UTC