- From: Philip Taylor <pjt47@cam.ac.uk>
- Date: Wed, 16 Sep 2009 14:27:27 +0100
- To: Ivan Herman <ivan@w3.org>
- CC: Manu Sporny <msporny@digitalbazaar.com>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Ivan Herman wrote: > Philip, > > sorry for the long delay but, as I promised I would do, I took up this > discussion with the SPARQL folks, too, just to check. Thanks for looking into this! > [...] > But, as I think we said in the previous mails, this in fact does not > affect the RDFa spec proper. We only say that proper RDF triples should > be produced by an RDFa processor, ie, a proper RDF XMLLiteral should be > generated. Does the RDFa spec actually say this somewhere, or is it just implicit? I don't see any mention of "proper" in the RDFa spec, or any similar requirements about the produced triples. The only relevant text I see for XMLLiteral is "The value of the [XML literal] is a string created by serializing to text, all nodes that are descendants of the [current element], i.e., not including the element itself, and giving it a datatype of rdf:XMLLiteral", which doesn't explicitly say anything about serialising to a value that is valid under the given datatype. It seems that some implementations don't get this correct - is that because their developers were unaware of RDF's XMLLiteral c14n requirement? If so, making it explicit (e.g. as a non-normative note) in the RDFa spec might help interoperability. (Otherwise maybe it's sufficiently obvious already, and implementers simply need to fix bugs.) > I also looked at the RDFa spec to see if the examples in the text are > o.k., but luckily I did not see any issues there. I may have missed one, > though... The RDFa spec examples seem okay in terms of c14n, but http://html5.digitalbazaar.com/specs/rdfa.html (in yesterday's draft) still has an example that looks like N3/Turtle syntax and has a non-canonical XML string. (The RDFa spec does have an example with "E = mc<sup>2</sup>: The Most Urgent Problem of Our Time"^^rdf:XMLLiteral which is missing the XHTML namespace, but that's a different issue.) > The current test suite is > pragmatic, insofar as many implementations (ie, the underlying XML > package) would indeed produce the first version of the XML Literal. > Maybe these tests should be flagged somehow to make it clear that there > is an issue there and that really really conforming processors should > produce the second version only... Well, if http://www.w3.org/TR/rdfa-syntax/#processorconf defined the "really really conforming RDFa processor" conformance class... :-) As it is now, conformance is a boolean property. If an RDFa processor produces invalid triples, it is not a conforming RDFa processor, and it should fail an RDFa conformance test suite. (Even if it's only a tiny bit invalid in an obscure way and it's really hard to implement correctly and nobody cares about the bug.) (If it's un-pragmatic to require that RDFa processors follow all the requirements of the RDF and RDFa specs, that seems to indicate a problem in the RDF and RDFa specs which should be fixed in the specs so they are adequately pragmatic, rather than hiding the problem in the test suite.) > Cheers > > Ivan -- Philip Taylor pjt47@cam.ac.uk
Received on Wednesday, 16 September 2009 13:28:04 UTC