- From: Ben Adida <ben@adida.net>
- Date: Fri, 27 Feb 2009 13:55:02 -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: > Acknowledge that there is a problem (CURIE as rel value), and resolve > it, instead of pretending it's not. If there is a problem, I disagree that it is with CURIEs in @rel in XHTML1.1+RDFa. I believe the problem is in trying to interpret a raw link-type string without knowing where it came from. HTML supports @profile, which modifies the meaning of @rel values. @profile="http://bens-crazy-parser.com" could easily process rel="(:dc:)title" into http://purl.org/dc/terms/title. HTML4 effectively has a default @profile, with a number of pre-specified link-types [1]. XHTML1.1+RDFa effectively has a default profile, too, where @rel values are interpreted as CURIEs (into URIs, of course.) In other words, any assumption one is making about generically parsing @rel without its language context is, in my opinion, strongly misguided. @profile can and does alter that interpretation. So if @profile can alter it for HTML4, then certainly the version of HTML has an effect on how @rel is interpreted. You can't interpret @rel blindfolded. As I suggested in a previous email, one simple way to resolve this potential conflict with the link-type RFC is to specify, in the link-type RFC, that while the semantic value of a link-type should be a URI, its syntax may be language-dependent. This shouldn't be controversial, because this is already the case given @profile. -Ben [1] http://www.w3.org/TR/REC-html40/types.html#type-links
Received on Friday, 27 February 2009 21:58:57 UTC