W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2012

Official Response to ISSUE-130 from RDF Web Apps WG

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 26 Feb 2012 18:14:49 -0500
Message-ID: <4F4ABCE9.9010604@digitalbazaar.com>
To: Henri Sivonen <hsivonen@iki.fi>
CC: RDFa WG <public-rdfa-wg@w3.org>, "Michael(tm) Smith" <mike@w3.org>
Hi Henri,

Thank you for your public feedback on the RDFa 1.1 documents. This is an
official response from the RDF Web Apps WG to your Last Call issue
before we enter the Candidate Recommendation phase for the RDFa 1.1

Your issue was tracked here:


Explanation of Issue

You had raised a number of concerns in the HTML WG requesting
clarification on which RDFa attributes were allowed on which elements in


Traditionally, XHTML+RDFa had allowed the @href, @rel and @rev
attributes on all elements. You felt that this would create confusion
among authors because it would add attributes that had their RDFa
functionality, but none of the functionality that authors have come to
expect for attributes like @href and @src. Additionally, you noted that
the HTML+RDFa specification was vague as to which attributes were
allowed on which elements.

Working Group Decision

There were a number of potential solutions proposed for this issue, the
full discussion can be found here:


The core of the clarification that the Working Group felt that they
should make to the specification is the following: It is the
responsibility of the Host Language to specify which RDFa attributes are
allowed on certain elements. This has always been the case for RDFa, but
the specification text seems to be unclear of this fact in certain
places. The Editor of the RDFa Core specification has made this clear in
the latest draft of the specification:


This makes it the responsibility of the HTML+RDFa specification to
specify where @src, @href, @rel and @rev are allowed.

Since @href, @rel and @rev were always defined on all elements in
XHTML1+RDFa, changing this would result in a backwards incompatible
change and so the Working Group decided to not change this behavior in
XHTML1+RDFa 1.1.

For HTML+RDFa, it was decided that it would be unwise to deviate from
where some of the more popular attributes, like @href and @src, could be
placed. The Working Group decided to not override where @href and @src
are allowed for HTML5 and XHTML5 - expect this change in the next
version of the HTML+RDFa specification.

Finally, the use of @rel and @rev everywhere cannot be removed without
cutting two of the more useful features of RDFa - namely forward
chaining and reverse chaining. Doing so would unnecessarily limit the
flexibility of the language. So, the Working Group decided that @rel and
@rev should still be allowed everywhere in HTML+RDFa.

The final resolution came to this:

RESOLVED: In RDFa Core, @href should be specified as an optional RDFa
attribute. In HTML+RDFa, @href is only allowed on elements that it has
traditionally been allowed on. In XHTML+RDFa, @href is allowed on all
elements. In XHTML+RDFa, XML+RDFa and HTML+RDFa, @rel and @rev are
allowed on all elements. (non-substantive)


For the purposes of the W3C Process, all of the resolutions that applied
to RDFa Core and XHTML+RDFa, resulted in non-substantive changes because
they were either vagueness or bugs in the specifications. HTML+RDFa will
require a second Last Call due to the substantive change above, and
other substantive changes made since that document entered Last Call.

The question of @src is addressed in a separate issue. You will receive
a response on that issue shortly.


Since this is an official Working Group response to your issue, we would
appreciate it if you responded to this e-mail and let us know if the
decisions made by the group are acceptable to you as soon as possible.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
Received on Sunday, 26 February 2012 23:15:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:30 UTC