Re: XMLLiterals and c14n

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 (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 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

Received on Wednesday, 16 September 2009 13:28:04 UTC