Ben Adida wrote:
I think what matters more is the end date, not the start date.
No. The RDFa task force was chartered for XHTML work, and that work was
specifically in a different working group than HTML5's work. The end
date of the HTML WG is December 2010, and that's not counting comments
by Ian that the WG will keep going until 2022. I strongly disagree with
the idea that other work should stop in the meantime, especially when it
belongs to a different charter.
I don't think anybody said it should stop. But, right now, the W3C has
*two* working groups working on XHTML, so this work needs to be coordinated.
Nope. A URI is a string, and in HTML4, you detect link relations simply
by string comparison.
This argument makes no sense, because a CURIE is also a string, but of
course a string is not necessarily a CURIE and also not necessarily a
URI. So interpreting a @rel as a URI *is* a new semantic interpretation.
That does not compute. Nobody proposed to interpret @rel as a URI.
Saying that it can use URI syntax is something different.
But later you say:
The fact that a link relation can use a string that conforms to the URI
syntax doesn't change the way how link relations are compared.
So what I think is going on here is that you mostly care about being
able to do a string comparison for raw @rel values, and you think that
interpreting a @rel value as a URI lets you continue to do that, so it's
all good.
Yes.
Not only is this a messy approach, it's also not true.
http://example.org:80/, http://example.org/, http://EXAMPLE.org/
represent the same URI, but they're not string-comparable. In other
words, if you're interpreting @rel values as URIs, string comparison is
a kludge at best.
Yes, the same way as in RDF (I think), and in XML namespaces.
The real problem is - again - that for a relation value of "foo:bar",
recipients do not know anymore what to do (or they'll have to ignore
RFDa and just continue to do a string comparison).
And again, as I've stated before, this is not a situation introduced by
RDFa. This is a situation that already exists.
If you choose to interpret @rel as URIs, you'll miss some cases by doing
string comparison.
Again. Nobody is proposing to interpret @rel as URI.
The problem of comparing arbitrary URIs is well-known, see
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2>. URIs
are used as identifiers in many places, and, as far as I can tell, they
are *always* compared as strings in these cases.
If you have @profile that says that rel="origin" is the same as
rel="canonical", you'll miss some cases by doing string comparison.
Yes, if you have several link relations with identical semantics, a
recipient will have to be aware of that. I don't see what this has to do
with the current discussion.
And if you have RDFa with non-classic prefixes, then you'll miss some
cases by doing string comparison.
What is a "non-classic" prefix?
Or, if you let the language tell you how to interpret @rel values,
you're in the clear all the time. String comparison of @rel values is
already a hack. With or without RDFa.
First of all, the trouble is that the language does *not* tell me how to
interpret the value of @rel. Treating HTML4, HTML5, HTML5 serialized as
XML, XHTML 1.0 and XHTML 1.*+RDFa as distinct languages for the purpose
of interpreting @rel is insane. Sorry.
Also, again, I disagree that comparing @rel values as strings is a hack.
BR, Julian
