Re: XML Schema draft populates the intersection of Language and InformationResource [ISSUE-14 httpRange-14]

On 28 Sep 2007, at 21:28, Dan Connolly wrote:

> On Fri, 2007-09-28 at 21:09 +0200, Richard Cyganiak wrote:
>> On 28 Sep 2007, at 20:24, Dan Connolly wrote:
>>> The 303 redirect stuff is almost always more trouble than it's  
>>> worth.
>>> I can't think of any cases other than legacy when I'd recommend it.
>>> Using doc#term is much more straightforward.
>>
>> I'm surprised to hear that.
>>
>> As I understand it, <doc#term> without 303 can't handle content
>> negotiation.
>>
>> If RDF is served at <doc>, then <doc#term> identifies whatever the
>> RDF says about it (so it could be anything). If HTML is served at
>> <doc>, then <doc#term> clearly identifies a section of an HTML
>> document. To me, that seems like an unacceptable ambiguity. A 303
>> from <doc> to <doc.rdf> and <doc.html> is needed to resolve this.
>>
>> So, are you saying that content negotiation is not worth the trouble,
>> or that the ambiguity doesn't matter?
>
> Some combination of the two.
>
> (a) I'm inclined to update the HTML media type spec to say
> that in a document with head/@profile present, what
> fragments refer to is not necessarily sections of the document;
> it's whatever the profile says it is (e.g. baseball players
> discussed in the document, etc).

I like this. But at the moment the RFC doesn't allow this  
interpretation, and I hear that @profile is at risk in HTML5. So,  
your inclination isn't quite enough to stop me from worrying about  
the ambiguity.

> (b) publishing only RDF without the HTML is pretty useful.

Yes, sure, no disagreement here. But content negotiation can be  
pretty useful too. That's why I'm surprised to hear that you never  
recommend 303s.

> If you decide later that you want HTML, you can add it.
> Note that it suffices to do a 303 redirect for .html;
> you don't need to redirect in both cases. You can
> just return the RDF in a 200 response to GET /doc .

I had suspected it could be done like this -- thanks for confirming.  
This “asymmetrical” approach is quite subtle though, and also hard to  
implement and everything but straightforward.

If you 303-redirect for both variants, then there isn't any benefit  
left over slash URIs.

My conclusion from this: Hash URIs are preferred only if you are sure  
that you never will need content negotiation. Otherwise, you simply  
have to swallow the bitter 303 pill, no matter if you go hash or  
slash. And since slash URIs are often shorter (no <#it> warts) and  
more flexible, they are the preferred choice if you want content  
negotiation.

For the purposes of the Cool URIs for SW document, I'm inclined to  
continue to defend this position.

Richard



>
>
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
>
>
>

Received on Friday, 28 September 2007 21:22:43 UTC