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

Re: New Editor's Draft for HTML+RDFa 1.1

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 11 Dec 2012 21:02:56 -0500
Message-ID: <50C7E5D0.2000908@digitalbazaar.com>
To: Niklas Lindström <lindstream@gmail.com>
CC: RDFa WG <public-rdfa-wg@w3.org>, Jeni Tennison <jeni@jenitennison.com>
cc: Jeni (who originally raised one of the sub-issues in this e-mail)

On 12/09/2012 04:35 AM, Niklas Lindström wrote:
> I found a problem in the latest draft. In  "3.1 Additional RDFa 
> Processing Rules", it says to use "HTMLLiteral" from the RDF 
> vocabulary. But according to "RDF 1.1 Concepts and Abstract Syntax: 
> 5.2 The rdf:HTML Datatype" [1], that should be just "HTML". So
> replace the two occurrences of "HTMLLiteral" with "HTML".

Fixed in the latest Editor's Draft, will have a pubrules-ready WD later

> Also, I think it's great that @value is supported. IIUC, it means
> that @value from <input> elements also can be captured with RDFa,
> correct? But I wonder why @value is defined to override @content, and
> not vice versa? I don't recall the reasons for that. (I was expecting
> @content to work just like @resource overrides @href. I.e. to always
> override any host language specific attribute; in this case,
> @value.)

Here's the issue that led to the feature:


The original e-mail by Jeni Tennison:


and the resolution:


It is troubling that @value overrides @content... seems like a bad thing
to do. Can anybody on the list remember why @value overrides @content?

Also keep in mind that the side-effect of adding support for @value is
that @value is also used on the INPUT and LI elements in HTML5, which I
don't think was intended when we added this feature. I'm personally fine
with leaving the feature in there, and changing it so that @content
overrides @value if it exists.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Problem with RDF and Nuclear Power
Received on Wednesday, 12 December 2012 02:03:32 UTC

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