Re: [public-webapps] Comment on Widget URI (3)
Hi Larry, On Dec 9, 2009, at 19:08 , Larry Masinter wrote: 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? I am sorry that you perceived my intent as being one of insult. I have nothing if not respect for you. Rather, my intent was merely to proffer a candid characterisation of your comment, as originally phrased. The term drive-by comment is one made against a specification in passing without the diligence and conscientiousness to participate in the follow-up discussion; and typically to then re-iterate it later. I believe that the term was coined during the denial of service by LC-comment conducted against SVG Tiny 1.2 — I may have mistakenly taken its usage to be more widespread. Since you had made this comment before, and since it had been argued against, doing the same thing yet again while presumably expecting different results can be understood as either 1) a lack of diligence in paying attention to the outcome from the same action performed previously (i.e. a drive-by comment); 2) the proverbial madness; or 3) deliberate process-based obstruction. Given the options, I elected to consider you neither mad nor deliberately obstructive. Thank you for now taking the time to discuss our previous response as part of this comment. 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. It appears that my non-native and therefore imperfect command of the many English vernaculars has led me to the mistaken belief that emphasising can was rather universally used as an elided apophasis to strongly imply should not. Since apparently that is not the case, I apologise for the confusion and shall endeavour to speak more clearly in future. That having been said, the sentence after the one you cite is I am very much unconvinced that the cost/benefit analysis weighs in its favour; and the conclusion of my post is 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:. The same message further indicates at the very least that thismessage: is so unclearly specified that its definition could be vastly improved simply by existing; that it appears to be unclear how relative URIs are resolved; that I cannot find a clear interpretation of what it does without exegesis through elimination and even then remain uncertain; that we'd have to map a widget package onto multipart/related messages (with no obvious benefit and potential incompatibilities); that bringing in MIME baggage is hardly something one feels comfortable doing nowadays; that our L10N model has no correlate in RFC 2557; that the implementation status of thismessage is pretty much unknown; and that all we get from the reuse is a label. The length of the analysis I provided in the message you quote is several times the length of what I will stretch generosity to call the definition of thismessage that RFC 2557 provides. I must admit to being rather baffled that you concluded from that that I would consider thismessage more carefully. I am not sure how much more carefully it could be considered without appealing to Deconstructionism, and one is generally fond of not going there. The one and only thing that thismessage has going for it is that it is registered. Frankly, that's not much to go on. Given that we thankfully now have higher standards for registering schemes, I would content that the best path forward would be to clean up and unregister thismessage. If you replace the string widget with the string thismessage We could certainly change the string of the scheme's name, but what of the MIME baggage that thismessage brings in? We certainly want none of it; and to be honest why should we? At some abstract distance they can be seen to be somewhat vaguely related, but then again so are HTTP and FTP. Should we also have FTP use HTTP URIs? After careful analysis, informed by your comments, all I can find to say about thismessage is that it's utterly underspecified, related to MIME somehow, and has its name in the registry's parking lot; while the widget URI scheme is far better specified even if perhaps imperfectly and entirely unrelated to MIME. We could perhaps squat
Re: [public-webapps] Comment on Widget URI (3)
On Tue, Dec 15, 2009 at 6:09 PM, Robin Berjon ro...@berjon.com wrote: The term drive-by comment is one made against a specification in passing without the diligence and conscientiousness to participate in the follow-up discussion; and typically to then re-iterate it later. I believe that the term was coined during the denial of service by LC-comment conducted against SVG Tiny 1.2 — I may have mistakenly taken its usage to be more widespread. For the record, drive-by commenting exists in bugzilla.mozilla.org, along with drive-by reviewing (a form of commenting where one gives a review, typically negative).
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:ro...@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
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/
