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

Re: Official Response to ISSUE-128 from RDF Web Apps WG

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 04 Mar 2012 21:16:59 -0500
Message-ID: <4F54221B.2070208@digitalbazaar.com>
To: "Michael[tm] Smith" <mike@w3.org>
CC: RDFa WG <public-rdfa-wg@w3.org>
On 02/26/2012 09:52 PM, Michael[tm] Smith wrote:
> Resolving this by adding a statement saying that the empty string is
>  allowed on all RDFa attributes is acceptable to me, but I think it
> needs to be qualified in some way; specifically, I'd suggest this:
>
> "an empty string for the value of any RDFa attribute MUST be allowed
> as conforming unless a Host Language specifically disallows the
> empty string for a particular attribute"

Mike, we took your advice and clarified a few things during the telecon
last week. The first clarification is this:

RESOLVED: Host Languages are allowed to specify the valid lexical space
of an element's attribute value.

RDFa Attribute Value Conformance in Host Languages
http://www.w3.org/2010/02/rdfa/meetings/2012-03-01#RDFa_Attribute_Value_Conformance_in_Host_Languages

We hope that the resolution further clarifies that it is a host language
that specifies the conformance criteria for attribute values. This
ensures that the HTML5+RDFa won't create any unnecessary conflicts
between the HTML5 specification and HTML5+RDFa specification. I believe
the only conflict might be @rel/@rev everywhere at this point. In
general, the goal is to create as little incompatibility between
HTML5+RDFa and HTML5 attributes as possible.

Further editorial language that clarifies the situation will be placed
into the RDFa Core 1.1 specification before it reaches PR status.

Does this resolution address your remaining concerns?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Monday, 5 March 2012 02:17:24 UTC

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