@rel attribute discussion
From RDFaWiki
Contents |
Overview
Mark Nottingham brought up an issue with the W3C TAG regarding XHTML1.1+RDFa interpreting the @rel attribute as a CURIE, in particular because XHTML1.1+RDFa syntax is finding its way into HTML4 [1] [2].
Mark's goal is to interpret @rel as either a registered link-type from a newly defined IETF registry, or a URI [3].
In the course of the discussion, Julian (among others) argued that @rel should have the same syntax no matter the version of HTML in which it appears [4].
It is the RDFa's Task Force's opinion that there is no technical issue or real-world problem with RDFa's use of @rel. We do hope that HTML5 will adopt RDFa in some form close to its current syntax, and we hope the TAG will agree that this is a useful direction for the HTML WG to explore.
A few more details on the point of view of the RDFa Task Force:
@rel has always been CDATA
@rel in HTML4 and XHTML1.0 is defined as a CDATA field with special-cased link-types (next, previous, copyright, etc..). It has never been a syntactic URI the way @href is.
The RDFa task force, and the RDFa specification, agree that @rel should be evaluated into a URI as often as possible, though we believe that the syntax of @rel already varies across uses of HTML. In RDFa, we use the CURIE syntax to express URIs.
HTML 4.01 specifies @rel and @rev as being Link-Types, which are CDATA. Ad-hoc uses of @rel include Dublin Core, which uses notation such as "DCTERMS.title" [5], OpenID which uses "openid.server" [6], and eRDF which uses "schema.foaf" [7]. These are neither URIs nor registered link types, but they clearly show a prefix-based syntax for representing URIs. eRDF, in particular, allows the prefix to vary and yet mean the same thing depending on prefix declarations, e.g. dc and dcterms.
@profile in HTML4 affects @rel
@profile in HTML4 affects the interpretation of @rel in a way that may depend on the rest of the document. Thus, RDFa's processing of @rel is similar to existing standards. The tuple (@profile, @rel) is not sufficient to determine the interpretation of @rel, because the rest of the page markup may play a role, depending on @profile.
GRDDL [8] is a prime example of this, where @profile points to GRDDL, which in turn looks at @rel="transformation", which indicates how to interpret other @rel attribute values. eRDF, similarly, expects @profile to point to eRDF, which then looks for @rel="schema.*", which then indicates how to interpret other @rel values.
It is thus an incorrect assumption that @rel can, on its own, be interpreted consistently even within a single version of HTML. Knowing the version of HTML and its complete page markup is required to properly interpret @rel.
Of course, it's okay for specifications such as Link-Type Header to ignore @rel values it doesn't understand because it cannot interpret @profile. In the same vein, Link-Type Header may choose to ignore @rel values that are not pre-registered Link-Types if it is unwilling to parse RDFa. In either case, Link-Type Header needs to know how to parse the HTML version in question, and what specific rules that version of HTML may have with respect to interpreting @rel.
RDFa in HTML5 discussions ongoing
The RDFa task force is in active discussions with the HTML WG to find an acceptable way to embed RDFa in HTML5, while hopefully maintaining the same @rel syntax to ensure that RDFa can be consistently interpreted across HTML versions.
A number of implementors (including Yahoo and Creative Commons) have found it beneficial to interpret RDFa using the current XHTML1.1+RDFa syntax even when the host document is HTML4. Though we have not endorsed this use in any of our specifications, we believe it is an essential step to determining whether RDFa in non-XML HTML is viable. So far, we have had no concrete implementation trouble reports, even for large implementations such as Yahoo's.
Some have raised the use of @xmlns in non-XML HTML documents. This seems to present a problem with parsers whose APIs both hide access to the @xmlns attributes *and* fail to properly maintain the stack of declared prefixes (which all XML parsers we know of do just fine.) While this use case seems quite limited and more of a bug than an inherent limitation, the task force is discussing the possibility of introducing @prefix rather than @xmlns:* in both XHTML and HTML to steer clear of this issue.
RDFa's use of @rel does not conflict
RDFa's use of @rel does not conflict with existing uses of @rel, since RDFa explicitly ignores values that are neither link-types nor properly prefixed CURIEs.
If one were to use @rel="http://purl.org/dc/terms/title" in their XHTML1.1+RDFa, without ever declaring the "http" prefix, an RDFa parser should ignore that value, given that it is a syntactic CURIE without proper resolution. In other words, other parsers are free to continue to parse this @rel as a URI if they so desire.
