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

Re: RDFa in HTML 5

From: Philip Taylor <pjt47@cam.ac.uk>
Date: Sat, 23 May 2009 12:53:54 +0100
Message-ID: <4A17E3D2.6030108@cam.ac.uk>
To: Sam Ruby <rubys@intertwingly.net>
CC: Manu Sporny <msporny@digitalbazaar.com>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Sam Ruby wrote:
> I will [...] say that if such markup is going to be widely 
> deployed, and if there is tooling created to process this markup -- and 
> both of these appear to already be true -- then it would be helpful if 
> there was a spec.

I think that's how I see things - I'm not interested in promoting the 
use of RDFa, but if people are going to implement it and use it anyway 
then I would like interoperability, and the best way to promote 
interoperability is to have a spec and test suite, and it looks like 
some more work will be needed before the specs and test suites are 
sufficiently complete.

(It's kind of like how HTML 5 specifies the behaviour of <marquee> - 
it's not promoting that feature (it's even a conformance error if you 
use it), but it's widely implemented and used and some people like it, 
so it's necessary to specify how it works.)

> Shane's document is definitely a promising start.  It, however, does not 
> address the questions that Philip posted on 14 May[1], nor has anybody 
> stepped forward to answer such questions.

Shane responded in 
<http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0107.html> 
and indicated he would look into some of the issues, and it's only been 
a week since then, so I don't feel like I'm being unacceptably ignored.

In any case, it may be helpful to rephrase the questions more precisely, 
as in 
<http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0177.html>:

Given each of the inputs in 
http://philip.html5.org/demos/rdfa/tests.html (markup in the rightmost 
column), what should the "Expected output" column say? and where do the 
specifications have the necessary conformance requirements for each case?

(That collection of tests is far from complete, but I think it 
illustrates some of the relevant issues.)

Once those questions are answered, there are separate questions about 
how good the answers are (e.g. ideally the rules for extracting 
languages and base URLs from elements, and for resolving URLs, and for 
splitting strings on whitespace, etc, would be identical to what HTML 5 
requires, and ideally it would be consistent with other versions of HTML 
too), but it's hard to discover those issues until some kind of 
behaviour is explicitly defined for every case.

I believe my document does define behaviour for all those cases, though 
not necessarily the most sensible behaviour and not necessarily with the 
most sensible style for writing the definitions.

> I am concerned that people are "going too crazy" in deploying both 
> content and tooling without a proper definition, and that inevitably 
> means that fragmentation has already occurred, and the longer the proper 
> documentation is lacking, the greater the fragmentation will be and the 
> harder it will be to address.
> 
> Am I unique in having this concern?

That's the main concern I have - my test page shows the output from 
three implementations of RDFa-in-text/html, and there is significant 
divergence around edge cases, and I would expect similar divergence in 
other implementations that are being produced (e.g. by Yahoo and 
Google). People will inevitably write broken content that happens to 
work in the tool they've tested with, and it will result in a big mess 
(see e.g. the HTML parsing rules), so it's important to encourage 
convergence between all the implementations before it's too late.

(I also think that encouraging convergence to some behaviour is more 
important than working out the 'right' behaviour to converge to, so when 
current implementations agree with each but disagree with the specs 
(e.g. for <div xmlns:0='http://example.org/' property='0:test'>) it may 
be most sensible to spec what the implementations already do. But I 
guess that depends on how quickly the implementations could be modified 
to conform to a stricter spec.)

>> * Philip's document starts this fragmentation process by re-defining
>> CURIEs and the RDFa processing rules - which many agree is a very bad
>> thing, even though we like the concept of a HTML5+RDFa document.
> 
> I am confident that Philip will agree that the important thing is that 
> the questions he posed on 14 May[1] be addressed by any such document, 
> and that the document he produced was a totally unofficial unfinished 
> and experimental very rough initial attempt to address such questions, 
> and will be quickly discarded should something better materialize.

I do agree.

> I continue to believe that if fragmentation is the biggest concern, then 
> the ever widening gap between specification and deployment is the most 
> important thing to be addressed at the moment.

I do agree with that too.

-- 
Philip Taylor
pjt47@cam.ac.uk
Received on Saturday, 23 May 2009 11:54:41 UTC

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