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/
