Subject: Status of Link header

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Sep 2008 16:50:23 +1000

For those wondering what/where/how things are going with the Link  
header draft <http://ietfreport.isoc.org/idref/draft-nottingham-http-link-header/ 
 >, I'm currently working on an -03 version. Potential changes include  
(feel free to discuss);

  - Re-adding the 'rev' attribute (I've had a few requests for  
specific use cases; not yet convinced either way)
  - Considering adding a 'hreflang' attribute
  - Clarifying the requirements for registering relations WRT format- 
specificity

Any comments or other input would be appreciated.

Cheers,

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

---

From: Shane McCarron <[email-masked]>
Date: Fri, 12 Sep 2008 08:54:06 -0500

Mark,

I think that you should defer to the spec at 
http://www.w3.org/1999/xhtml/vocab for the definitive list of rel and 
rev values.  That document is written in XHTML+RDFa and is maintained as 
part of the W3C process for defining XHTML.

Mark Nottingham wrote:
> header draft 
> <http://ietfreport.isoc.org/idref/draft-nottingham-http-link-header/>, 
> I'm currently working on an -03 version. Potential changes include 
> (feel free to discuss);
>
>  - Re-adding the 'rev' attribute (I've had a few requests for specific 
> use cases; not yet convinced either way)
>  - Clarifying the requirements for registering relations WRT 
> format-specificity
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Sep 2008 16:03:03 +0200

Shane McCarron wrote:
> ...

a) What's the registration process?

b) Why would it be a good idea to have relations between resources being 
defined specifically for one vocabulary? Shouldn't relation names be 
re-usable between HTML, XHTML, Atom, and other formats (*)?

BR, Julian

(*) for instance those that are not XML based and need the Link header 
to transport it

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 12 Sep 2008 10:13:35 -0400

On Fri, Sep 12, 2008 at 10:03 AM, Julian Reschke <[email-masked]> wrote:
>> http://www.w3.org/1999/xhtml/vocab for the definitive list of rel and rev
>> values.  That document is written in XHTML+RDFa and is maintained as part of
>> the W3C process for defining XHTML.
>> ...
>

+1

Mark.

---

From: Shane McCarron <[email-masked]>
Date: Fri, 12 Sep 2008 09:29:23 -0500

Sorry - let me be more precise.  It appears to me that the current draft 
is deferring to the simple relation descriptions from HTML 4.  Those 
definitions are very, very old and there has been work done recently on 
this with the W3C.  These have been recently updated and extended as 
part of the XHTML 2 Working Group / RDFa Task Force activity defining 
RDFa.  That activity defines a mechanism for extending the collection of 
relationships via RDF, and also codifies the pre-defined "simple" 
relationships such as previous.  I was only saying that if you want this 
document to be consistent with the direction HTML is headed, you should 
rely upon the definitions in RDFa.  Those definitions are contained in 
the referenced vocabulary document.

As to registration - I don't personally expect there to be extensions to 
the collection of simple relationships.  If there are, it would be done 
through the W3C processes and the vocabulary document updated.

Instead, I expect RDF vocabularies to be created that extend the 
collection.  Since the draft Link: header document defines a 
relationship as a "URI-Reference" I think this is entirely consistent 
with the definition used for values of @rel in RDFa.  After all, RDF is 
about expressing semantics via URIs. 

For more on RDFa, you might look at http://www.w3.org/TR/rdfa-syntax

As an aside, RDFa syntactically uses "CURIEs" to express values for 
@rel.  This is a lexical space concept, not a value space concept.  In 
the value space, @rel values are URIs, so I believe this to be entirely 
consistent with the view that Link: header rel parameters are 
white-space separated URI-References. 

Julian Reschke wrote:
>> rev values.  That document is written in XHTML+RDFa and is maintained 
>> as part of the W3C process for defining XHTML.
>> ...
>
> b) Why would it be a good idea to have relations between resources 
> being defined specifically for one vocabulary? Shouldn't relation 
> names be re-usable between HTML, XHTML, Atom, and other formats (*)?
>
> BR, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Sep 2008 17:06:37 +0200

> is deferring to the simple relation descriptions from HTML 4.  Those 

Not really, it adopts both the values from the current IANA registry for 
Atom relations and HTML4.

> RDFa.  That activity defines a mechanism for extending the collection of 

Well, they have also been updated by the WHATWG.

I personally do not believe that a markup language related WG is the 
right place to do this, as link relations should be portable across formats.

> the referenced vocabulary document.

I believe that the WHATWG's proposal to use a Wiki as registration 
process is a non-starter. But so is a process that requires knowledge of 
RDF.

> through the W3C processes and the vocabulary document updated.

I don't think this reflects reality (see the set of Atom link relations).

> For more on RDFa, you might look at http://www.w3.org/TR/rdfa-syntax

I do not disagree that RDF *could* be used to do that. People who want 
"short" relation names should be able to get them through a controlled 
process; an IANA registry would fulfill that need.

People how are happy with a "long" name (a URI) should be able to mint 
them easily. If they want to use RDF to describe that relation, so be 
it, but I don't think a requirement to do so will fly.

> the value space, @rel values are URIs, so I believe this to be entirely 

URIs or IRIs?

> white-space separated URI-References.

Yes.

The concern about CURIEs is related to the fact that, despite what you 
wish, there are other people "defining" link/@rel, and it would be bad 
if the definitions disagreed on the lexical representation.

Best regards, Julian