- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 04 Apr 2009 12:31:19 +0200
- To: "www-tag@w3.org" <www-tag@w3.org>
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