Re: XMLLiterals and c14n

Philip Taylor wrote:
> 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?

Well it is implicit in the sense that the RDFa spec says it has to
generate an RDF graph (no serialization is defined by RDFa).

> 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.)

O.k., I see what you mean. Let us see what the editors of the docs say.
Certainly any additional explanation should be informative, so can be
part of an edited version of the rec in future. But I remember this
issue was hotly debated back then...

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

Ah, I did not look at that one. I leave that to Manu:-)

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

What I meant, actually, is to make the SPARQL kosher, but add some
explanation which means that if implementation fail then they have some
clue what is happening, and flag those tests accordingly (or maybe
provide a weaker not 100% conform version of the SPARQL query).

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

There is no problem in the RDFa spec in my view, but the RDF spec,
well.. it is certainly a contentious issue that has raised eyebrows
elsewhere already. The SPARQL people (as a result of me rocking the
boat, thank you:-) consider filing some sort of an errata for RDF on
that. But, well, at the moment we have the standard as it is...



>> Cheers
>> Ivan


Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:

Received on Wednesday, 16 September 2009 13:58:32 UTC