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

Re: Request to publish HTML+RDFa (draft 3) as FPWD

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 22 Sep 2009 15:45:50 -0700
Cc: Shane McCarron <shane@aptest.com>, Jonas Sicking <jonas@sicking.cc>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Message-id: <CDC4A9B5-1FFD-4B28-B82E-2416BCA48A7E@apple.com>
To: Henri Sivonen <hsivonen@iki.fi>

On Sep 21, 2009, at 11:55 PM, Henri Sivonen wrote:

> On Sep 22, 2009, at 01:01, Shane McCarron wrote:
>
>> Okay, I understand what you are looking for.  I think that your  
>> suggested text is correct when talking about the DOM and Infoset  
>> processing.  But the processing rules in section 5.5 are not  
>> written from a DOM or Infoset perspective - at least not  
>> exclusively nor intentionally.  We really, really, really were  
>> talking about the syntax and then the extraction of data from  
>> structures that conform to that syntax.
>
> I think it's a fundamental spec writing error to specify RDFa  
> processing in terms of syntax as opposed to defining it in terms of  
> the data structure abstractions that HTML parsers and XML processors  
> output.
>
> An HTML parser or an XML processor sees the bits that come from the  
> wire. Assuming that you intended an RDFa processor to be layered on  
> top of an HTML parser or and XML processor, the RDFa processor never  
> gets to see the bits on the wire. It gets to see the output of the  
> HTML parser or the XML processor. Therefore, it's wrong to define  
> the behavior of the RDFa processor in terms of bits on the wire and  
> it would be correct to define it in terms of the output data  
> structure abstractions of HTML parsers (namespace-aware DOM) or XML  
> processors (the Infoset). (DOM Level 3 defines a mapping between the  
> DOM and the Infoset, so you can avoid some duplication there.)
>
> Alternatively, if an RDFa processor were defined to operate on the  
> bits on the wire, RDFa shouldn't give the impression that it's  
> layered on top of XML or HTML. Instead, it should define everything  
> from the bits on the wire up and conspicuously warn implementors  
> that they shouldn't try to use off-the-shelf XML processors or HTML  
> parsers. (But that would be fundamentally bad, too.)
>
> I don't support the publication of HTML+RDFa as an FPWD in the HTML  
> WG, because I think HTML WG deliverables shouldn't have such  
> fundamental spec writing errors.

Do you want this taken as an objection Call for Consensus on  
publishing? If so, could you respond to my email asking for  
objections, just to make it clear?

(Note: I don't think errors in the mechanics of sepc construction  
constitute a very strong reason to object to FPWD; it would be a good  
reason to object to to Last Call if not fixed by then. I think it's  
not very hard to fix HTML+RDFa to consistently describe operation in  
terms of an abstract tree model, and I expect this will need to be  
done to get a draft the WG can agree on.)

Regards,
Maciej
Received on Tuesday, 22 September 2009 22:46:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT