ISSUE-35 RDFinXHTML-35 (also ACTION-240)

I just had another look at 
<http://rdfa.info/wiki/%40rel_attribute_discussion>, and was considering 
editing it, but then decided not to -- it seems it hasn't been set up 
with the purpose having a discussion over there (no complaint, just 
explaining).

Here are a few comments:

> @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.

That's true, and nobody disagreed with it. But CDATA *can* hold a URI, 
so an absolute URI always has been a legal @rel value.

> 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.

I agree that there already have been cases where the interpretation 
depended on information outside the @rel value, without having that 
interpretation being the same one everywhere, and being properly 
specified in the W3C.

RDFa has added another of these interpretations, contributing to the 
confusion.

> 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.

Note: both [5] and [6] appear to apply only to link/@rel (not a/@rel). 
I'm not arguing these should be handled differently, but the dependency 
on prefixes/profiles declared below <head> is easier to accept if the 
only instances where they are used are below <head> as well (the scoping 
and view-source/copy/paste problem).

WRT [6]: in "openid.server", is "openid" a prefix (declared somewhere 
else), or just a fixed string? I think it's the latter, in which case 
this would be a counter-example (in that the rel value *is* understood 
universally, has not been declared in HTML4, and no @profile attribute 
is around).

> @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.

If @profile *always* affects the interpretation of @rel in HTML4, this, 
by definition also applies to XHTML 1.1, right?

And if this is the case, why doesn't RDFa specify a profile itself, then?

> 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.

For the record: I think the phrase "...which in turn looks at 
@rel="transformation", which indicates how to interpret other @rel 
attribute values" is misleading.

What happens is that the source document is fed into a transformation, 
and that produces RDF/XML. So, except for very simple examples, it's not 
  that simply looking at the XSLT code will tell you how to interpret 
@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.

This is the key issue.

If to interpret @rel "properly", a consumer needs (1) tons of special 
cases  (DC? eRDF? RDFa?), (2) access to information from different 
document parts (head/@profile, special entries in head/link...), and (3) 
also the original document type, this is not going to fly.

(1) How many special cases should consumers handle? How is the 
processing triggered if profiles aren't used in practice, or not even 
defined (RDFa)?

(2) What if they are not available (syndication), or broken (due to 
copy/paste errors)?

(3) Depending on where the processing happens, that information may or 
may not be available. Making the semantics of @rel depend on the source 
document's document type simply is too fragile in practice.

We need *simple* processing rules that work everywhere, and we shouldn't 
give up trying to get there.

> 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. 

I would buy this argument if RDFa would use a non-generic way to define 
these prefixes.

Reminder: all of this wouldn't have been a problem if RDFa would have 
followed the W3C's advice not to deploy CURIEs where URIs are already 
allowed.

BR, Julian

Received on Saturday, 4 April 2009 10:32:09 UTC