Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

On 28/02/2009, at 4:19 AM, Ben Adida wrote:

> Mark,
> CC indeed recommends using RDFa, as we describe in detail here:
> which we published once RDFa was REC.

Thanks, will have a look.

> So while 90% of our work has been entirely in the context of standards
> groups, 10% has stepped out in front of the standard as  
> unobtrusively as
> possible. Yahoo parses RDFa, in XHTML and in HTML, and it's been  
> working
> extremely well (they happily ignore non-prefixed CURIEs in @rel  
> values).

Are people using RDFa in HTML using the profile mechanism, or xmlns,  
or both? Do they flag the use of RDFa in any way (like @version does  
for XHTML+RDFa)?

It seems like this is an interoperability minefield, to be honest...

> I think the only section in [1] that potentially conflicts is 4.2,  
> which
> is quite short:
>   4.2.  Extension Relation Types
>   Applications that don't merit a registered relation type may use an
>   extension relation type.  An extension relation type is a URI
>   [RFC3986] that, when dereferenced, SHOULD yield a document  
> describing
>   that relation type.
>   Extension relation types MUST be compared in a case-sensitive
>   fashion, character-by-character.
> Would you consider tweaking this section to indicate that certain
> syntaxes, e.g. XHTML+RDFa, may further process the raw attribute value
> to yield a URI? I certainly agree that, semantically, @rel should be  
> a URI.

The draft already accommodates different syntax for different  
serialisations; the section you're referring to is not syntax- 
specific. If you (or anyone) has suggestions about how to make that  
more clear, I'm all ears, but I believe it's already stated quite  

What I can see doing is adding information in the appendices  
(alongside that for HTML4 and Atom) about relations in XHTML (after  
their syntax is clarified, see other parts of this thread) and XHTML 
+RDFa; that seems pretty straightforward.

What isn't straightforward at this point is the status of link  
relations in HTML4; at this point it looks like there are multiple  
syntactic conventions there. I suppose in a way that's not surprising,  
given the limitations of the Profile mechanism, but like Julian, it  
would be good if we could come to one way of doing this per syntax,  
and ideally one way of doing this across the HTML family of languages  
(although that may be asking too much).

As it sits, a generic parser can't reliably identify the link  
relations in an HTML4 document just by looking at it; if I understand  
what's being done here, the relation "ab:foo" might mean radically  
different things in two different documents, even if they have the  
same profile attribute, thanks to the use of xmlns. This is bad.

In terms of potential paths forward for HTML4 (not necessarily  
mutually exclusive):

1) Can CC require (or at least recommend) the use of @profile, and  
mandate that the cc: prefix always be used? This would help  
disambiguate these relations in a way that's more compatible with  
generic parsing.

2) The Link draft can add a note that XHTML+RDFa-style syntax might  
appear in HTML4; implementations can either consider them locally- 
scoped extension relations (i.e., not meaningful in a global scope),  
or try to parse them if they like.

3) If relations are going to be used more frequently in HTML4, some  
guidelines of best practice would be really helpful. The Link draft  
suggests a way to get from @profile + @rel in the HTML4 appendix;  
review of that would be appreciated, as I'm beginning to suspect it  
may need revisiting.


Mark Nottingham

Received on Friday, 27 February 2009 23:01:24 UTC