- 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