Re: On reading material for f2f - Web Linking

Hi TIm,

Thanks for the feedback; if that's indeed what it is. I'm not sure if this is feedback on the draft, or just discussion leading up to feedback on the draft from the TAG as a whole. Could you clarify?

Regardless, some responses below;

On 06/12/2009, at 5:07 AM, Tim Berners-Lee wrote:

> - 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.

Intermediaries already have to preserve the ordering of values for a single header field in HTTP. How is this a disaster?


> - "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?

They are definitely not well-defined. See:
  http://www.w3.org/mid/2BDD98C6-F223-47DC-AF4B-BCBF6E232813@gbiv.com

While I have no doubt that you and others had a crisp idea in mind when 'rev' was minted, it is today probably the single greatest source of confusion to Web authors using links. 


> - 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/)?

As you note below, they're absolute URI.


> 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/.

There was strong feedback from the HTML5 community against assuming a base URI for these, because it complicated parsing. Given that anything with that URI prefix is registered, what does doing this buy you?


> - title*=UTF-8'de'letztes%20Kapitel"    Really hanging double quote on the end?

As Julian mentioned, this is fixed in -07.


> - 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.


Making IANA maintain an RDF-based registry is a non-starter; they don't have that capability, and furthermore it will expose their servers to arbitrary loads.

We're not at a place where there will be an XML-based registry document available (see -07). It should be a simple matter for someone to produce a GRDDL or similar transformation to create RDF if you'd like.

Cheers,


--
Mark Nottingham     http://www.mnot.net/

Received on Sunday, 6 December 2009 23:11:36 UTC