- From: Tim Berners-Lee <timbl@w3.org>
- Date: Sat, 5 Dec 2009 13:07:22 -0500
- To: TAG List <www-tag@w3.org>
___________________________________ Web Linking draft-nottingham-http-link-header-06 - The HTTP link header spec says "Likewise, the relative ordering of links in any particular serialisation, or between serialisations (e.g., the Link header and in-content links) is not specified or significant in this specification; applications that wish to consider ordering significant MAY do so. " That is heading for disaster. If an application (what is an application?) treats the ordering as significant, then any intermediary or translator must too, which messes up the whole chain. Just say, the ordering is NOT significant. - "The "rev" parameter has also been used for this by some formats, and is included here for compatibility with those uses, defined by this specification." Alas. It is a design feature, which allows {A chapter B} to be stated in A or B. And why define it in the syntax and not give its perfectly well defined semantics? - In relation-type, How to distinguish a relative URI (parsed relative to the requested resource URI) and a token (parsed relative to http://www.iana.org/assignments/relation/)? Hmmmm "Note that extension relation types are REQUIRED to be absolute URIs" Oopps.. why? This was a mistake in the Namespaecs spec, as there are times (like when a CSV file is converted into RDF) that the namespaces are local. Unwise to block it just because we can't think of a use now. Unless it is to solve the ambiguity. In which case more consitent say parse it w r t http://www.iana.org/assignments/relation/. - title*=UTF-8'de'letztes%20Kapitel" Really hanging double quote on the end? - Add a section of 6.2 to say that IANA will maintain an RDF document at the address defining each registered name as an RDF Property, with at least rdfs:label in at least one language and rdfs:comment and a reference to the specification in which the relationship is defined. And that client software must not look up this file more than once in its installed life. ______________________________________
Received on Saturday, 5 December 2009 20:39:25 UTC