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

Re: XMLLiteral handling in RDFa in HTML

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 28 May 2009 00:57:59 -0400
Message-ID: <4A1E19D7.2030402@intertwingly.net>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: Ian Hickson <ian@hixie.ch>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, HTMLWG WG <public-html@w3.org>
Manu Sporny wrote:
> Ian Hickson wrote:
>> On Tue, 26 May 2009, Manu Sporny wrote:
>>> I don't believe that there is any such thing as an malformed XMLLiteral 
>>> in HTML5... is there? Can anybody think of an example of an invalid 
>>> XMLLiteral in an html5 parser?
>> If you're asking if an HTML5 parser can generate a DOM that cannot be 
>> serialised as XML, the answer is yes, there are a number of ways to do 
>> this.
> Thanks for the examples and the links, Ian (and Sam). I've created a
> number of local tests that should be incorporated into the HTML+RDFa
> test suite. I'll try and glean some more from the documents each of you
> linked to.
> Perhaps what we need is a test harness that will take the document
> contents of each 110+ XHTML+RDFa test cases and shoves them into a
> series of different (X)HTML DOCTYPES to determine which test cases
> result in different triples based on the underlying RDFa parser and DOCTYPE?
> It would give us some idea of where triples deviate most often based on
> DOCTYPE as well as helping developers create more robust RDFa processor
> implementations.

I've left a comment on your wiki page.  Whether or not it is the 
dominant usage or not, I'm presuming that the ultimate definition of 
RDFa is not intended to preclude Javascript implementations running in 
the browser from ever being fully compliant.  Is that a fair assumption?

The reason why I say this is that browsers have settled on a behavior 
where the MIME type is the primary signaling mechanism, and the DOCTYPE 
is at *most* a secondary signaling mechanism.  In particular, look at


> -- manu

- Sam Ruby
Received on Thursday, 28 May 2009 04:58:33 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:47 UTC