Toby Inkster wrote:
On Thu, 2009-07-09 at 16:58 +0200, Julian Reschke wrote:
If I had a solution that is compatible both with RDFa and full-URIs in
@rel, I would already have proposed it. That's why I've been
complaining for so long: I think the use of CURIEs instead of
safe-CURIEs in @rel is a big problem. (It's ok in new attributes, but
problematic in @rel/rev).
Safe CURIEs are important in @about/@resource because those attributes
are primarily intended for URIs. The @rel attribute was not previously
used for URIs, so no disambiguation mechanism was needed.
The @rel attribute previously existed, and was not specified to use
CURIE indirection, thus the change introduced by RDFa (not qualified by
@profile, btw) potentially changes the meaning of existing content.
Furthermore, RDFa is not specified (yet) for HTML; so the interpretation
of @rel depends on the context it appears in (such as DOCTYPE). This is
bad, because in many cases the final consumer of the @rel value (think
XSLT) will not know about the context.
Yes, @rel in *Atom* is a URI, but no previous recommendations for HTML
or XHTML have recommended URIs in @rel, and the current HTML5 draft
doesn't either. Nor am I aware of any widely non-W3C specifications that
use URIs in @rel. Google's rel=canonical and rel=nofollow are simple
tokens. Pingback uses a simple token, and so do microformats. So I'm not
sure where these pre-existing uses of URIs in @rel are supposed to be
found.
If you're concerned by compatibility between HTML's @rel and Atom's
@rel, then don't be. They're completely incompatible. Atom's is not a
token separated list at all.
No, I'm not concerned about the difference to Atom. What I'm concerned
with is the difference to RDFa-less XHTML and HTML.
BR, Julian
