W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > November 2009

Re: Call for Review of XHTML Test Cases 142, 147, and 154

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 10 Nov 2009 23:11:29 -0500
Message-ID: <4AFA3971.4000902@digitalbazaar.com>
To: RDFa Developers <public-rdf-in-xhtml-tf@w3.org>
TC142: approved
TC147: approved
TC154: tentatively approved pending discussion and erratum

TC154 will result in an XML parsing error. We have, to this point, never
approved a test case that generates an XML parsing error. Clearly, if
the document is not well-formed, we can't parse it reliably, and
therefore cannot produce a stable graph per the XHTML processing rules.

So, if we are going to approve this test case, we're going to have to
make a decision on what kind of RDF graph should be produced when there
is a parsing error. We could do one of the following:

1. A blank RDF graph (a graph with no subjects) is produced.
2. An RDF graph is produced, but that graph not undefined.
3. The RDF graph that is produced contains all of the triples leading
   up to the parsing error.

#1 is not very useful because one may not want to throw the entire graph
away because of a parsing error at the end of a document. We'd certainly
take issue with this approach as there are many pages that Fuzz
partially parses, but fails due to some XHTML parsing issue at the end
of a document. We can still act on most of the triples in the page, so
#1 would move us in the wrong direction, IMHO.

#3 is easy for SAX-based parsers to accomplish, but not for parsers that
may require a valid XHTML document before creating a DOM of some kind.

#2 blends the best of #1 and #3 - it allows RDFa processors to generate
as many triples as they can before failing, but doesn't require
stream-based processing of the XHTML document. The down-side is that
behavior isn't defined, other than that the RDFa processor should
generate a graph.

So, if we do approve this TC154, it should be a negative test and the
SPARQL should provide further documentation that is a negative test.

Even if we don't approve TC154, we should generate an erratum clarifying
that XHTML+RDFa depends on XML 4th edition.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Establishing an Open Digital Media Commerce Standard
http://blog.digitalbazaar.com/2009/09/28/a-digital-content-commerce-standard/
Received on Wednesday, 11 November 2009 04:11:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:05 UTC