Re: interesting hash in URLs

Jacek Kopecky wrote:
> So what does break? A client without scripting will not be able to
> dereference that ID, for one, but under what circumstances is this a
> problem? (And I don't see "you can't view it without Javascript" as a
> real problem because Javascript has become a part of the Web for me,
> just like PNG or Flash.)
>   
If something is unspecified, then nothing will break because everything 
goes. :-)

But the unspecified semantics will hurt data interoperability in the 
semantic web.  Consider if I were to write a machine agent to process 
the following two resources.

a) http://example.com/x/a
b) http://example.com/x#a

We all know what it means if (a) get back a 404.  But what about (b) 
when we get a 200 on the primary resource but find nothing about the 
"#a".  So, should the agent treat these two cases in the same manner or 
differently?

Second, what if "http://example.com/x#a" does exist but in a different 
representation.

For instance, "http://xmlns.com/foaf/spec#term_person" does exists in 
the "text/html" representation but not in the "application/rdf+xml" 
representation.  Similarly, "http://xmlns.com/foaf/spec#person" is in 
the RDF but not in the HTML document.
Personally, I think FOAF does a good job avoiding the name clash. But is 
it an error, if they do clash? If so, why? And from the name alone, how 
can I tell from the URI alone which MIME type representation has that 
URI? And should I try all kinds of MIME type to see if I can get that or 
not?

I don't think the unspecified semantics matters that much in the human 
web because if the fragment id breaks, the browser will do nothing but 
return the primary resource.  And user can keep "his" application going 
by clicking on some link.  But for a machine agent, it will be a 
different story because it needs explicit instruction.  And to give the 
explicit instruction, we need a clearly specified semantics. 

Xiaoshu

Received on Monday, 13 August 2007 16:58:41 UTC