- From: Ben Adida <ben@adida.net>
- Date: Sat, 28 Feb 2009 08:34:36 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: noah_mendelsohn@us.ibm.com, Henri Sivonen <hsivonen@iki.fi>, Mark Nottingham <mnot@mnot.net>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, public-xhtml2@w3.org, "www-tag@w3.org WG" <www-tag@w3.org>
Julian Reschke wrote: >> Our >> work began before the HTML5 group had anything to do with W3C. So I >> don't think we did anything rogue or unilateral. > > 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. > 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. 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. 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. > 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. If you have @profile that says that rel="origin" is the same as rel="canonical", you'll miss some cases by doing string comparison. And if you have RDFa with non-classic prefixes, then you'll miss some cases by doing string comparison. 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. -Ben
Received on Saturday, 28 February 2009 16:37:01 UTC