Toby A Inkster wrote: > On 26 May 2009, at 08:14, Henri Sivonen wrote: > >> In a reasonable layering, the RDFa processor is layered on top of an >> HTML parser, in which case the RDFa parser can't in the general case >> tell if the input would have been well-formed if processed as XML. It >> seems like a bad idea to define RDFa processing in terms of the source >> bytes instead of defining it in terms of the output of the HTML >> parsing algorithm. > > > Indeed. That is a good argument in favour of solution #3 from my > previous message. > > Most current RDFa parsers do seem to sit on top of a separate (X)(HT)ML > parser, just looking at a DOM tree which can be fairly reliably > serialised to XML, so this solution probably has the smallest > implementation cost for them. Smallest being zero:-) at least in my implementation (just to take that as an example). I think Henri is absolutely right, the RDFa processing is, in effect, defined on the DOM. The way I understand it, the HTML5 spec clearly defines what the DOM representation of the HTML5 document is, and that is all what counts. This should also solve the issue around XML Literal: once the DOM is available, generating an XML Literal for RDF is not a problem, I would expect DOM implementations to do that for you for free, so to say. > The exception is XSLT-based > implementations; but, given that XSLT processors can't operate on HTML > by definition, this seems to be a moot point. > That we cannot help... Ivan -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Tuesday, 26 May 2009 13:04:45 UTC