Test case regarding XML Literals and octets

At 09:50 03/07/29 +0100, Graham Klyne wrote:

>At 00:46 29/07/03 -0500, pat hayes wrote:
>
>>>Are 'binary octets' different from 'octets'?
>>
>>I have absolutely no idea. :-)

>Anyway, returning to the original question (Are 'binary octets' different 
>from 'octets'?), I think the answer is:  not for any meaningful purpose as 
>far as RDF is concerned.

Here is a test case that I am proposing to get clarity on this.
I guess this test would be classified as a datatype-aware entailment
test.

Do the following two RDF fragments entail each other?

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:eg="http://example.org/">
  <rdf:Description rdf:about="http://example.org/foo">
    <eg:bar rdf:parseType="Literal">XML</eg:bar>
  </rdf:Description>
</rdf:RDF>


<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:eg="http://example.org/">
  <rdf:Description rdf:about="http://example.org/foo">
    <eg:bar rdf:datatype="http://www.w3.org/2001/XMLSchema#hexBinary"
        >584D4C</eg:bar>
  </rdf:Description>
</rdf:RDF>


Comment: "584D4C" is the hexBinary representation of "XML" encoded
in UTF-8 (which for this case is the same as ASCII). The current
(post-lastcall) RDF spec says that XML fragments denote their
exclusive canonicalization, a sequence of octets after encoding
with UTF-8. The value space of hexBinary is sequences of (binary)
octets (http://www.w3.org/TR/xmlschema-2/#hexBinary).

This seems to indicate that the current spec says that this test
is true (positive entailment test). However, I think equating these
conceptually very different things (XML complex types and a specific
simple type) is highly problematic. I propose that this test be
added to the negative entailment tests (with a corresponding one
making the same statement with regards to parseType="Literal"
and base64Binary, which needs a bit more work for the base64
calculation), and that the spec be changed if necessary to make
this clear.


Regards,    Martin.

Received on Thursday, 31 July 2003 14:58:50 UTC