W3C home > Mailing lists > Public > public-xhtml2@w3.org > February 2009

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

From: Ben Adida <ben@adida.net>
Date: Fri, 27 Feb 2009 13:55:02 -0800
Message-ID: <49A86136.1040107@adida.net>
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.


[1] http://www.w3.org/TR/REC-html40/types.html#type-links
Received on Friday, 27 February 2009 21:56:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:40:04 UTC