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

On Tue, Feb 21, 2012 at 3:24 AM, David Booth <david@dbooth.org> wrote:
> Hi Jonathan,
>
> Attached are two versions of the "baseline" document
> http://www.w3.org/2001/tag/doc/uddp/
> containing my suggested changes.  They are in MS Word format (produced
> by OpenOffice).  One has "track changes" turned on, and shows
> (hopefully) all the changes.  The other simply shows the document as a
> whole with the changes incorporated.  (The formatting is a little screwy
> in this latter version because of "holes" left by deleted portions.)

While I appreciate the work that went into this, the upwards of 200
changes indicated by track changes are too much for me to process. If
the original text had been preserved for comparison that would have
helped; all I see in the track-changes version is "deleted" at the
side in a way that's very hard to read.

In fact I see also that many changes are not marked at all, which
makes processing even more difficult. Effectively I have to treat your
document as entirely new. In the time I have I simply can't compare it
to mine in detail - that would take days.

I suggest you turn your suggestions into a list of issues that can be
treated and decided independently. We can then run these in parallel
with dealing with ISSUE-57.

> The changes that I am suggesting are of two kinds: (1) substantive
> changes to better align this "baseline" document with the intent
> of the existing httpRange-14 resolution and background specifications;
> and (2) editorial changes to improve the readability and clarity
> of the document.

I could not identify any substantive changes, i.e. any that would
change the behavior of someone consulting the document, in a quick
scan of your document. If you could list these that would be helpful.

> I included them both at once: (a) because it was easier for me to
> make a single pass through the document, improving everything
> that I thought I could improve; and (b) because I thought it would
> be more helpful to others to see how the document as a whole
> would read with these changes.
>
> However, if you felt more comfortable doing so, you could just
> incorporate the substantive changes now and leave the
> editorial changes for me to make as a change proposal,
> in an additional step.
>
> Some further explanations that were too long
> to embed in the attached documents:
>
> 1. This document is partially written as though it is applicable
> to URIs in general, but it really only gets into the necessary
> detail to cover http: (and https:) URIs.  I think it would
> be better to only attempt to cover http: (and https:) URIs,
> since those are the ones that the httpRange-14 issue bears on.

The document *is* applicable to hash URIs in general, not just those
where the stem URI is an http: URI. This is because it derives from
RFC 3986, which is not specific to http:.

It easily *could* be applicable to hashless non-http: URIs since the
architectural notions of dereference, retrieval, representation, etc.
are not specific to http:.  The HTTP protocol is not specific to http:
URIs, either, and a change proposal I might suggest is to remove this
restriction, which I see no need for. The httpRange-14 idea is a
consequence not of HTTP or http:, but of retrieval, as far as I can
tell right now. (But I have asked the HTTP WG for clarification that
bears on this, we'll see what they say.)

In TAG discussion this subject has always been treated as an
architectural problem, which to me means that it is not special to the
http: scheme. Certainly the problem to be solved is not specific
either to http: or to HTTP; they are just the vehicles for the
proposed solution.

I continue to be open to taking back to the TAG the proposal to
restrict the discussion to http: (or HTTP, I am not sure which), or to
move the whole thing out of the TAG as being non-architectural. This
to me makes it more confusing, but so it goes. I suggest we take this
up at a later time, after progress has been made on ISSUE-57.

> 2. The title, "Understanding URI Hosting Practice as Support
> for Documentation Discovery" is too vague.  It sounds like it
> would apply to *any* kind of documentation whatsoever, when
> really it is only about URI definitions.

Hmm, I see what you mean, maybe "URI" should occur twice in the title?
Will think about this.

> 3. The current draft seems to be unnecessarily obsessed with
> differentiating statements conveyed under this protocol with
> truth in real life, as though such statements would otherwise
> be taken as truth.  This shows up in a number of places,
> such as: (a) in its concern about the term "authoritative"
> (as though "authoritative" imparts any authority beyond this
> specification);

This was a specific response to complaints that a document like this
cannot be authoritative for meaning, or even for anything that might
be called a documentation or definition, just as HTTP cannot be
authoritative for what is or isn't a representation of something. What
is correct regarding meaning and definition is application specific. I
agreed and sought ways to address this concern, which needs to be
addressed *somehow*.

I agree that it can be authoritative for what is or isn't a NUDC, but
it does so just by saying which representations are NUDCs.

Will note this as an issue.

> (b) in its use of the term "URI documentation"
> instead of "URI definition" (as though "definition" would imply
> too much);

This was a specific response to complaints that "definition" was too
strong and too specific, that I agreed with.

There are other aspects to URI documentation other than definition,
such as stability information.

> (c) in its use of the qualifying word "nominal",
> as in "nominal URI documentation carrier" (as though there is a
> need to distinguish the URI definition conveyed by this protocol
> from the *real* URI definition); and

You have misparsed this as {nominal URI documentation} carrier, where
it is clearly (I think) meant as nominal {URI documentation carrier}.
Clearly you can get one of these things and have it not carry any URI
documentation at all, in which case it would not be a URI
documentation carrier.  It is only nominally so (like "allegedly" in
the newspapers). I'm not sure how to make this more clear, and I see
no rhetorical way to get rid of the qualifier "nominal".

Maybe if I introduced some acronyms the grouping might be apparent -
introduce UDC, and then "nominal UDC", then shorten to "NUDC". But I
think you misread it because you anticipated a particular problem, and
most readers won't have this anticipatory difficulty.

Will note this as an issue.

> (d) in its mention that
> "URI documentation may not be correct".

But it might not be correct, in solving the problem that was set out,
which is to coordinate communication between a sender and a receiver.
The sender might use the URI at variance with the documentation, the
documentation host might change the documentation, other conventions
might apply locally (as they do in OWL, Memento, and maybe even HTTP),
and so on.

Again, this was added explicitly in order to address concerns of other
reviewers.

> 4. The abstract includes the disclaimer: 'There is no
> intention that the set of specified circumstances should be
> either "authoritative" or exclusive of other sources of URI
> documentation.'  I think this is unhelpful, counterproductive,
> and should be deleted, for these reasons:
>
>  - A protocol specification can and *should* state
> what bits are to be considered authoritative
> _under_that_protocol_.  The fact that something is authoritative
> _under_a_particular_protocol_ does not automatically make it
> "authoritative" in any legal or other sense.  Defining something
> as "authoritative" under a particular protocol is simply a means
> of describing an algorithm for choosing between potentially
> conflicting pieces of information.  If it is useful for a
> protocol to describe an algorithm in terms of authoritative
> versus non-authoritative information, then that is fine to do.
> For example, the HTTP 1.1 specification defines "authoritative"
> entity headers.  Nobody confuses that as conveying any sort
> of legal or other authority beyond the scope of that protocol
> definition.
>
>  - If a protocol specification gains such uptake in the
> community that conformance eventually becomes a legally binding
> social expectation, then that is a social and legal matter that
> falls entirely outside the scope of the specification itself.
> The specification itself should not attempt to make claims
> one way or the other about such matters.
>
>  - It sounds disparaging to the specification itself, to
> include such a disclaimer.  By comparison, the HTTP 1.1
> specification does not say that "There is no intention that
> this protocol be "authoritative" or exclusive of other transport
> protocols".
>
>  - The point of recommending a particular protocol is that we
> *want* the community to rally around one particular protocol
> (which may itself involve a wide range of options), rather
> than having the chaos of multiple conflicting protocols.
> The disclaimer undermines this purpose.
>
>  - This "baseline" draft is supposed to convey the intent of the
> current httpRange-14 decision, but the httpRange-14 decision
> has nothing like this disclaimer.  It appears to originate
> from personal opinion.

I will take this up in future TAG discussion of the document.

By the way I personally find "best practice" notes to be, most of the
time, pretentious and will resist them in any document I am
responsible for.

I won't be able to make all reviewers happy. My scan of your changes
indicate mostly editorial disagreement with other reviewers. The
document is crafted based on input I've received and mostly I don't
think I've taken positions unilaterally. To make progress I think
we'll have to start some kind of issue tracking for the document, with
changes given not as a long list of track-changes edits but as issues
with alternatives to weigh. I will look into this.

Jonathan

> BTW, I am near MIT, if you'd like to get together to work on this in
> person.
>
> Thanks,
>
>
>
> --
> 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 Monday, 27 February 2012 19:54:24 UTC