W3C home > Mailing lists > Public > www-tag@w3.org > February 2012

Re: Comments on draft "baseline" httprange-14 replacement

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Fri, 17 Feb 2012 16:04:17 -0500
Message-ID: <4F3EC0D1.7070601@arcanedomain.com>
To: David Booth <david@dbooth.org>
CC: Jonathan A Rees <rees@mumble.net>, www-tag <www-tag@w3.org>
(as chair...)

I don't claim to be sufficiently versed in the nuances of this to have a 
well formed opinion on Jonathan's text on the merits, but:

 From a process point of view, Jonathan's text is offered as a baseline to 
be used in an invitation for change proposals. I think the tradition, in 
groups such as the HTML WG, is that change proposals can range from minor 
tweaks, to complete replacements of the proposed text.

That being the case, why is it appropriate now to further delay the 
publication of the call for change proposals while trying to resolve the 
specific differences around Jonathan's text? Might it not be more effective 
to encourage Jonathan to publish the change proposal and baseline 
immediately, and thereby invite others (including of course you, David) to 
offer alternative text that you believe might be more acceptable to the 
community as a whole?

Thank you.


On 2/17/2012 10:42 AM, David Booth wrote:
> Jonathan,
> Review of: http://www.w3.org/2001/tag/doc/uddp/
> I started a detailed review of this document yesterday, but
> today I see that it has substantially changed.  Since you
> previously stated that your call for change proposals would
> be opened TODAY, I think it is quite unreasonable to give this
> document so little review time before it is frozen.
> Overall, this document is NOT yet ready for use as a baseline
> for httpRange-14 change proposals:
>   - As a baseline, this document should
> faithfully convey the intent of the existing httpRange-14
> resolution.  But it currently goes far beyond this, often
> including positions based on personal opinion that have no
> basis in the existing httpRange-14 decision.
>   - As pointed out by multiple people, the document strays
> into the murky tar pit of talking about the "meaning" of
> a URI.  This is a major tactical error.  It is unnecessary,
> and IMO reflects a persistent misunderstanding of semantic web
> architecture (which never should have been called "semantic"
> in the first place, as that term has led to no end of confusion
> and misconception).  Regarding "meaning" the rule should be
> simple: DON'T GO THERE.
>   - The document invents cumbersome terminology
> in an effort to be precise, rather than using well-established
> existing terms and clarifying those terms where necessary.
> This makes the document hard to read.
> I will try to follow up with more detailed comments, but wanted
> to get this out before today's deadline.
Received on Friday, 17 February 2012 21:04:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:42 UTC