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

Hi Noah,

I see the process as involving two steps:

1. Writing up the intent of the *existing* httpRange-14 resolution as an
actual protocol specification that is more clear and complete than the
terse email announcement of the original resolution.  The point of this
step is not to agree on what substantive changes (if any) should be made
to the original httpRange-14 resolution, but simply to provide a
coherent baseline specification reflecting the intent of original
httpRange-14 resolution, against which substantive changes could be
proposed.

2. A call for proposals to substantively *change* the existing
httpRange-14 resolution as formalized in step #1 (or alternatively,
ratify it as is).

Granted, these steps could be lumped together, but this means that major
architectural questions (step #2) would be mixed with editorial issues
(step #1).  And it also means that the TAG would be making a de facto
decision in advance to rescind the httpRange-14 resolution in favor of
whatever might come out of this process.

There is of course a risk in attempting to separate these steps if
people cannot agree on the intent of the original httpRange-14
resolution.  But that is not the major issue that I have observed, and
which I believe we are trying to address.  In general, I think its
intent is pretty well understood by those who have studied it.  Rather,
the problem is that is has not been uniformly followed (e.g., in the LOD
community), and this in my view is due both to the fact that the
httpRange-14 resolution has never been written up and promoted to the
level of a recognized protocol specification or standard, and because of
substantive architectural disagreements with it.

David

On Fri, 2012-02-17 at 16:04 -0500, Noah Mendelsohn wrote:
> (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.
> 
> Noah
> 
> 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.
> >
> >
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Friday, 17 February 2012 22:23:40 UTC