RE: [public-webapps] Comment on Widget URI (3)

Your reference to 'every drive-by "you should use this!" argument'
is mainly irrelevant to my comment and I assume your goal was
to be insulting, alluding to 
http://en.wikipedia.org/wiki/Drive-by_shooting -- unless you have
some other explanation for your intent?

The fact that you got similar requests (that there were
multiple "drive-by" arguments which were "just a rehash
of something we've seen before") would seem to as likely
indicate that there is a significant support for reuse
of other schemes, than as a validation of your position
that you need a new one.

I reviewed the document without having read every other
review, and I think that was appropriate.

You claim "Having done due diligence", but that would 
seem to make it easy to trivially supply what I asked for 
and which I cannot infer or guess: a single use case 
where the offered alternative ("thismessage" in my case)
is inadequate for providing "the desired properties of
identifiers and their relation to resources".  
Could you please supply one use case; surely anyone
familiar with the lengthy due diligence you allude
to would have a simple example?

Your previous reply:

  http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0972.html 

contains interestingly the statement that:

# I think that this demonstrates that, technically speaking,
# reusing thismessage: *can* be done.

It does go on to discuss the costs of doing so, but the
costs are all a matter of writing technical specifications
and updating the "thismessage" definition to clarify the
ambiguities which you alluded to, and not technical
impediments. I had frankly taken your previous note as
indicating that you would consider "thismessage:/"
more carefully.

>> Alternate Suggestion: Withdraw registration of "widget:"
>> and reference existing scheme.

> That would leave us with no way of addressing widget resources.
> Having just now implemented a widget runtime, I don't see how we could have 
> interoperability without them.

If you replace the string "widget" with the string "thismessage" and remove the
possibility of an (opaque, undefined, and unneeded by any documented use cases)
authority field, the widget runtimes can proceed, and would have a way of
addressing widget resources. There are no apparent use cases where the
the string "widget:" ever appears in any content. If this isn't the case,
it isn't clear from the definition of the URI scheme. Rather, it claims

# In general, authors of widget content use relative URI references.
and
# widget URIs identify them only on the inside of a package, irrespective
# of that package's own location.
and that
# Must not require widget developers to be aware of it for basic tasks

Since the references are relative, the scheme name shouldn't matter.
If it does matter, where?

I'll just take your "elephant manicures" comment as an attempt at
humor.

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


-----Original Message-----
From: Robin Berjon [mailto:robin@berjon.com] 
Sent: Thursday, November 19, 2009 5:13 AM
To: Larry Masinter
Cc: public-webapps@w3.org
Subject: Re: [public-webapps] Comment on Widget URI (3)

Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
> 3) ** Reuse URI schemes **
> 
> http://www.w3.org/TR/webarch/#URI-scheme includes   "Good practice: Reuse URI schemes"
> 
> "A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources."

The WebApps WG is well familiar with webarch. In this instance, I would like to emphasise "when it provides the desired properties of identifiers and their relation to resources". The WebApps WG has discussed this topic with luminaries and experts in both the TAG and the community at large, and to this date, while we have learnt about many obscure and sometimes poorly defined URI schemes, none has provided us with a solution.

We've long reached the point where every drive-by "you should use this!" argument is just a rehash of something we've seen before. Having done due diligence, I feel confident that we haven't found an existing URI scheme that, as per AWWW, "provides the desired properties of identifiers and their relation to resources".

> The draft suggests there are many other schemes (with merit) already proposed, but that these existing efforts, "rather than identify packaged resources from the outside, widget URIs identify them only on the inside of a package, irrespective of that package's own location.", but this seems to indicate that the requirements for "widget" URIs are weaker, not stronger.

Actually that wasn't the intended meaning, but since it can be construed thusly (and since you made another comment indicating that it was hard to understand) I have removed this section (it was just meant to be informative anyway).

> Suggestion: Supply use cases where reuse of existing schemes (including "thismessage:/") do not provide the desired properties of identifiers and their relation to resources.

I do not believe that it would be a useful attribution of resources from the WG to document this in the specification. The process of looking at alternatives has been conducted in public and under strong scrutiny. If someone wishes to document this process, they are welcome to do so, and all the information is available. It would, however, do nothing to lead the web to its full potential.

To further the point, I would like to underline the fact that you suggested using thismessage:/ before, and that the WG provided as thorough a debunking of that idea as can be made given such an underspecified scheme, to which you didn't respond:

  http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0972.html

> Alternate Suggestion: Withdraw registration of "widget:" and reference existing scheme.

That would leave us with no way of addressing widget resources. Having just now implemented a widget runtime, I don't see how we could have interoperability without them.

> Alternate Suggestion: Provide guidelines so that "widget:" can be used for other applications 
>  that need a way of referencing components within ZIP packages; rename "widget:" to use
>  a scheme name that is appropriate for this broader application.

Anyone who uses the widget packaging can reuse the URI. Extending widget URIs to apply to all Zip archives would be inappropriate the properties of relating identifiers to resources would have to change (see AWWW and Widget P+C for more details). We could also make them reusable for elephantine manicure, but likewise those resources are obtained in entirely different ways.

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

Received on Wednesday, 9 December 2009 18:15:35 UTC