Re: test case 0011

Hi Johannes/Ivan,

First, we have to recognise that this is a well known problem in
RDF-world, too; if you serialise your data with RDF/XML you get
exactly the same issues as we are talking about here.

Also, the problem of XML canonicalisation is not one of our making;
the ability to compare two XML literals is tricky in any environment.

Anyway, some aspects of this might not be too hard to do. For example,
the general idea of canonicalisation is to add all of the current
namespaces to the top element; we have all of those values in our
'prefix mappings' variable, so they would be easy to dump out.

But the big problem for us is that the XML literal is not an element.
Canonicalisation says nothing about that, from what I can see. RDF/XML
does, but what it says is merely that the content serialised must be
well-formed XML if placed inside some arbitrary XML element (so you
couldn't serialise "</banana>", for example).

The only fool-proof resolution I can see is to *always* wrap the XML
literal in an element that is well known, such as:

  <rdf:XMLLiteral>
    ...
  </rdf:XMLLiteral>

But the problem with *that* is that it's not up to us. :( We are RDF
citizens, and so we must play nicely with the rest of the RDF world,
and since our triples may be consumed by systems that are completely
unaware of their origin, we need a solution like this to be proposed
outside of our group.

So, perhaps the compromise for now, is to say that if the XML literal
has an element at its root, then all of the in-scope prefix mappings
are dumped onto that element as @xmlns structions. Any values that
already exist on the element should of course, not be overwritten.

Actually, I've just thought of another approach...why didn't I think
of this before!

Why don't we say that rdf:XMLiteral always copies in the element that
it is on, not just the children? That way there is always a root
element, and all of the various canonicalisation rules can apply. We
still copy on the prefix mappings (and maybe language), but that's all
we'd need to do (very easy to implement, and you don't even need to
check for duplicates, since you are dealing with the current context).

Regards,

Mark

On 05/03/2008, Johannes Koch <koch@w3development.de> wrote:
>
>  Ivan Herman schrieb:
>
> >> If you serialise a DOM document fragment in Java using either DOM3 or
>  >> JAXP transformations, the serialisation contains namespace
>  >> declarations. E.g. serialization via DOM3 (namespace-aware Apache
>  >> Xerces and serializer) results in
>  >>
>  >> E = mc<sup xmlns="http://www.w3.org/1999/xhtml"
>  >> xmlns:xml="http://www.w3.org/XML/1998/namespace"
>  >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">2</sup>: The
>  >> Most Urgent Problem of Our Time
>  >>
>  >
>  > Yep. Whereas what I would do, using my pedestrian (ie, namespace-less)
>  > XML library is to artificially modify the DOM tree that has to be put
>  > out as XMLLiteral by adding the namespace declaration manually on the
>  > top level elements only.
>
>
> If there were any. As you have to serialize "all nodes that are
>  descendants of the [current element], i.e. not including the element
>  itself", you don't necessarily have one top-level element. In the case
>  of test 0011, you have to serialize a node-list containing
>
>  1. a text node
>  2. an element node
>  3. a text node
>
>
>  > Ie, the output would differ character-wise...
>
>
> I'm not sure about the xml and xsi namespace declarations. But
>  implementations may also differ in including these in the serialization.
>
>
>  --
>  Johannes Koch
>  In te domine speravi; non confundar in aeternum.
>                              (Te Deum, 4th cent.)
>
>


-- 
  Mark Birbeck

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.x-port.net | http://internet-apps.blogspot.com

  x-port.net Ltd. is registered in England and Wales, number 03730711
  The registered office is at:

    2nd Floor
    Titchfield House
    69-85 Tabernacle Street
    London
    EC2A 4RR

Received on Wednesday, 5 March 2008 11:08:23 UTC