Re: [widgets] Authorities will never have authority?

My compromise solution would be to specify something that current
widget: URI minters (producers) can write that is assured to connote
NOTHING to all future widget: URI consumers, for example the empty
string. That would futureproof the field without forbidding it. It has
pretty much the same effect as what Larry proposed (optional
authority). You could for example say that the empty string has this
property. The problem with the current spec is that no such value is
provided, so all producers will live in fear (given the way it's
currently worded) that something they say now will have unintended
meaning in the future.

I don't think fear and uncertainty is what's intended. The fix to the
text is very simple.

Jonathan

On Tue, Dec 22, 2009 at 8:15 AM, Robin Berjon <robin@berjon.com> wrote:
> 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 Wednesday, 23 December 2009 20:10:35 UTC