W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2003

C14N in RDF

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Fri, 31 Jan 2003 15:21:37 +0100
To: <w3c-rdfcore-wg@w3.org>
Cc: <reagle@w3.org>

Joe Reagle has made some helpful comments reviewing our use of XML C14N:


In my reply,
I suggest he is raising two issues -
  Problems to do with equality of XMLLiteral.
  confusion about the use of C14N or EXC-C14N

Both arise from the desire we had when we finalized this design (in Cannes)
to not rule out certain difficult cases.
These are illustrated by the following example which embeds a piece of XSLT
in RDF:

    xml:base="http://www.w3.org/2002/03owlt/I5.4/consistent002" >
    <owl:DatatypeProperty rdf:ID="p"/>
    <owl:FunctionalProperty rdf:about="#p"/>
    <owl:Thing rdf:ID="i">
       <first:p rdf:parseType="Literal"
        xmlns:eg="eg:a"><xsl:template match="eg:foo"/></first:p>
       <first:p rdf:parseType="Literal"
        xmlns:eg="eg:b"><xsl:template match="eg:foo"/></first:p>

The fragment <xsl:template match="eg:foo"/> uses the namespace prefix eg but
not visibly.
The position in the LC WDs is that implementations which wish to be clever
can correctly preserve the namespace, but this is not REQUIRED.
e.g. using ARP the following fragment preserves the namespace binding for eg

<owl:Thing rdf:ID="i">
  <first:p rdf:parseType="Literal"
   ><xsl:template match="eg:foo"

However, this is not interoperable.

Moreover, the position taken causes interoperability problems also in the
easier cases e.g.


(this case is non-interoperable even without the comment, because of the rdf
namespace which optionally can be included in the literal value).


In summary, I think we should think again about whether we made the right
trade off between the desire to not rule out advanced uses (embedding XSLT,
XML Schema's and xsi:type attributes) and good solutions to the simple case

Received on Friday, 31 January 2003 09:21:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:20 UTC