W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: RDFa in HTML 5

From: Shane McCarron <shane@aptest.com>
Date: Fri, 22 May 2009 08:57:15 -0500
Message-ID: <4A16AF3B.5010107@aptest.com>
To: Philip Taylor <pjt47@cam.ac.uk>
CC: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Philip,

Philip Taylor wrote:
> Seeing as people are implementing RDFa parsers for text/html, I guess 
> it would be good to have a specification that says how they should work.
>
> http://www3.aptest.com/standards/rdfa-html/ doesn't answer the 
> questions I'd want answered (e.g. in 
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0102.html), 
> and HTML 4 seems to make it impossible to express an answer. 
I'm sorry that my draft "profile" document doesn't answer your 
questions.   Of course my intent is to evolve that profile so that, in 
conjunction with the other RFCs, Candidate Recommendations, and 
Recommendations it normatively references, it represents a thorough 
description of the model for embedding RDFa in HTML documents.
>
> I've not seen anyone else working on this, so I started writing a 
> rough draft at <http://philip.html5.org/docs/rdfa/>. Some of it is 
> copied from the RDFa-in-XHTML specification, and just tweaked to use 
> some new definitions and to share concepts (like base and lang) with 
> HTML 5 and to cope with text/html parsing (for xmlns:* attributes). 
> The CURIE definitions are new, since I didn't see any existing 
> document that defined them in an appropriate way.
Well - here we are going to have to disagree.  Copying materials from 
other specifications and then modifying those materials is a good way to 
get divergence.  The reason the document I prepared is very thin is that 
there is no need, in my opinion, to duplicate materials.  If there are 
things in the CURIE spec that need clarification, then that is the place 
to fix those.  If there is confusion about the processing model for RDFa 
as defined in its Recommendation, then we should issue errata or 
re-issue the Recommendation.  Any other way lies madness, IMHO.
> There are several unresolved design issues (e.g. handling of 
> case-sensitivity, use of xmlns:* vs other mechanisms that cause fewer 
> problems, etc) - I haven't intended to make any decisions on such 
> issues, I've just attempted to define the behaviour with sufficient 
> detail that it should make those issues visible.
Yes, and you brought those issues up in a response to my announcement.  
Thanks for that.  I have been incorporating feedback from you and others 
into a revision, and hope to have an updated draft available shortly.
>
> The current draft is far from complete or correct, but it shows 
> roughly the way I'd like to have things defined (and I hope it's 
> roughly the way that HTML5/WHATWG people would like it to be defined, 
> in order to support implementers and to be testable), and maybe it 
> could end up being useful for something, so I'm just throwing it out 
> here for discussion.
>
There is always room for documents that expand on the normative 
definition.  Heck, there are whole publishing companies that grew up 
just to deal with that!  If the intent of your document is to expand the 
discussion and provide additional data for people building 
implementations, I think that's great!  If the intent is to act as the 
basis for some new specification, I think that is very bad.  It 
duplicates and changes existing Recommendations and Candidate 
Recommendations.  That can't end well.

Personally, I would rather have a quality test suite that exercises the 
specification and ensure that suite gets extended to clarify any edge 
cases that implementors are curious about.  For example, I feel the 
CURIE syntax definition is very clear.  But I could see how people would 
ask questions like "is 0:lala" a legal CURIE?  The answer is clearly no 
from the spec, but having a test that ensured such a CURIE was ignored 
by a conforming processor would be a fine thing.  And FWIW this sort of 
thing happens in the RDFa Task Force all the time.

Let's work together to get your questions answered by the right people 
in the right places.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Friday, 22 May 2009 13:57:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:03 UTC