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 thismessage's parking space by reusing its label, but I am at a loss to see why that would be a good idea.

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

Received on Tuesday, 15 December 2009 16:10:02 UTC