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

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

Received on Saturday, 28 February 2009 17:00:33 UTC