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
pj...@cam.ac.uk
