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

Re: XMLLiteral handling in RDFa in HTML

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 28 May 2009 10:11:23 -0400
Message-ID: <4A1E9B8B.3050609@digitalbazaar.com>
To: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
CC: HTMLWG WG <public-html@w3.org>
Sam Ruby wrote:
>> 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?

Yes, I think that is a fair assumption to make. We've tried to be as
careful as possible to ensure that a wide selection of technologies are
able to implement RDFa in XHTML. The same care should be taken when
addressing RDFa in HTML.

> 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
> 
> http://dev.w3.org/html5/spec/Overview.html#the-initial-insertion-mode

While I agree that this is the reality in the browser-world, we must
also take into account that documents can and will be processed offline,
where access to the MIME type is not possible at all times.

For in-browser implementations, one could make the argument that a DOM
that differs from its HTML or XHTML representation on disk, even if the
on-disk representation is corrupt, constitutes a different document and
therefore may produce a different set of triples.

Put another way, if somebody applies a transformation to an XHTML
document via XSLT, and produces a different XHTML document, we wouldn't
expect the set of triples to necessarily be the same between the pre-
and post-transformed document.

Similarly, if a browser applies a variety of transformations to an HTML4
document to create the HTML DOM, we shouldn't expect the same set of
triples to always be generated from the modified document. This concept
could be applied to harmonize RDFa with most things that html5lib generates.

This same high-level approach could be taken in the (X)HTML+RDFa case -
but, of course, the devil is in the details.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/
Received on Thursday, 28 May 2009 14:12:02 UTC

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