Re: Review Comments for draft-nottingham-http-link-header-05

Hi... I just found this thread, so sorry for stirring it up again, but
thought I'd weigh in as I've been around this track once or twice.

On the question of normative status I'm afraid I agree with Julian. On
the question of merit I'm mostly with Sean, but I have to report that
I've not yet found an argument for the httpRange-14 rule that has made
sense to someone who's not already disposed to agree with it, and I
can forgive anyone who finds the limits of "information resource"
unclear.

My understanding is that the rule given in the TAG's resolution
concerning the httpRange-14 issue is a GPN ("advice to the
community... for the sake of removing ambiguity"). According to my
reading of the TAG charter the rule, like the documents designated as
"findings," is technically on rec track, but the next volume of AWWW
is a long way off, and the advice may find itself transformed before a
rec comes out. Even if it does eventually end up in a recommendation,
it may still be presented as a GPN, not a protocol requirement.

And by the way the rule does not derive from RDF and is only implied
by a very particular reading of the HTTP and URI RFCs. At best you can
ask people to respect AWWW (which goes beyond HTTP/URI/RDF) and not
use the same URI to "identify" both a document and a property.

Echoing what Julian says, if you (Sean) think a normative statement is
needed, encourage the TAG (or some other WG) to generate a
recommendation that provides one.

As for HTTP RFC authors, for Larry's opinion see
http://lists.w3.org/Archives/Public/www-tag/2009Jan/0120.html (that's
in the thread on www-tag where this same issue was discussed).

Of course one can still try to convince others to follow the rule on
its own merits. There is no stick, so try the carrot.

Jonathan

On Fri, Apr 17, 2009 at 4:26 PM, Julian Reschke<julian.reschke@gmx.de> wrote:
> Sean B. Palmer wrote:
>>
>> On Fri, Apr 17, 2009 at 7:43 PM, Julian Reschke wrote:
>>
>>> A TAG finding is not a standard.
>>
>> Well, who decides how much standing a TAG finding, or a W3C
>> recommendation, or an IETF RFC, or an ISO standard has?
>
> Dunno.
>
> What I was trying to say is that if the W3C wants to make a normative
> statement, it should do so by issuing a Recommendation, because that's the
> closest thing in the W3C Publication System to a Standard.
>
>> But even socially speaking, there is some obvious substance here: the
>> TAG finding was announced by Roy Fielding, an author of the HTTP RFC.
>> And the TAG chair is another author of the HTTP RFC.
>
> I happen to be aware of that, as I've been spending some time editing the
> latter lately :-).
>
> Anyway, before you cite Roy as authority sanctioning the httprange finding,
> you may want to search the TAG mailing list archive for more of his emails
> around this topic
> (<http://lists.w3.org/Archives/Public/www-tag/2008Feb/0086.html> is an
> example).
>
>> This isn't just somebody's opinion on a mailing list, it's a W3C
>> resolution of something that had been causing intense argument for
>> years and years.
>
> And continues to do so.
>
>>> And even if it was, not stating anything about retrieval
>>> wouldn't conflict with it.
>>
>> Well it makes the Web Linking specification inconsistent. If you can
>> use extension relations as RDF properties, then the only way you can
>> tell whether they're valid is to dereference them. And Web Linking
>> says you SHOULD NOT dereference them... so why force people to do it?
>
> Could you elaborate why you need to dereference the URI of an RDF predicate
> to validate it?
>
>> You can be compatible with RDF, or you can be incompatible. But at the
>> moment it's being quasi-compatible, which isn't good.
>>
>>> (I'm honestly trying to understand the implications!).
>>
>> The most concise way that I can put it is this:
>>
>> If Link is supposed to be compatible with RDF, then you have to
>> explain why you're not mandating 303 responses for extension
>> relations. If Link is not supposed to be compatible with RDF, then you
>> have to let RDF people know so that they won't be misled.
>
> Again, please cite a normative document that states that the URI used to
> identify an RDF predicate needs to be a non-information resource.
>
>>> Extensibility is already there for Atom relations
>>
>> It'd be interesting to survey how often Atom IRI relations are used in
>> proportion to Atom registered relations.
>
> Dunno.
>
>> ...
>>>
>>> Reversed domain names would be a new approach to do distributed
>>> extensibility. If this would be used, people will build bridges between
>>> the new system and URI based extensibility anyway.
>>
>> Possibly, but possibly not? The HTML WG link types registry makes it
>> look like people care about extensibility. But, to be cynical, perhaps
>> they really care about politics and transparency and so on?
>
> What registry do you mean? The one proposed by the WHATWG? The one proposed
> by the XHTML2 WG?
>
> As far as I can tell, HTML4 didn't have a registry, which is part of the
> problem we need to solve.
>
>> Those are good things to care about, but it's not Web Linking's place
>> to try to fix that. The point should be to judge how often people are
>> really going to want to implement extensions. How can we gauge how
>> popular it will be?
>
> We have evidence that people make up new relation names. Whether a single
> central registry is sufficient to deal with that is another question.
> History shows that people try to avoid registration procedures, thus having
> another way to avoid naming conflicts seems to be good.
>
>>> I believe that distributed extensibility based on URIs is good.
>>
>> Where do you use it, incidentally?
>
> Myself? In WebDAV (properties, protocol extensions such as condition names
> or report names). In JCR (Java Content Repository), identifying property and
> node types. When extending other people's XML vocabularies. All the time,
> really.
>
>>> If the semantic web community is so convinced about it, why isn't
>>> there a W3C Recommendation which clearly states how to deal with
>>> RDF predicates that happen to be identified by an HTTP URI?
>>
>> I'd guess because the RDF Core WG was disbanded before the TAG
>> resolution was made, and because it tends to be covered in notes such
>> as the following:
>>
>> http://www.w3.org/TR/swbp-vocab-pub/
>> Best Practice Recipes for Publishing RDF Vocabularies
>>
>> http://www.w3.org/TR/cooluris/
>> Cool URIs for the Semantic Web
>>
>> Again I'm not defending this design, and my proposal is to eschew the
>> thing entirely. But if you're going to encourage compatibility with
>> RDF, it's got to be done right if Web Linking to be a decent
>> specification.
>
> I think it would be helpful if you could point out how having link relation
> URIs resolve to 200 actually is in conflict with an RDF related spec, and
> also how it would have an effect in practice (given the fact that DC URIs
> today do not resolve to 303s either).
>
> BR, Julian

Received on Monday, 15 June 2009 13:21:06 UTC