xom-interest AT lists.ibiblio.org
Subject: XOM API for Processing XML with Java
List archive
- From: "Michael Kay" <mike AT saxonica.com>
- To: "'Elliotte Harold'" <elharo AT metalab.unc.edu>
- Cc: 'xom-interest' <xom-interest AT lists.ibiblio.org>
- Subject: RE: [XOM-interest] XPath Namespace Nodes rethink
- Date: Tue, 1 Feb 2005 08:56:32 -0000
XSLT has all these problems. The solutions aren't perfect, but they are
workable. Although XSLT doesn't move nodes, it does copy them, and the
problems are essentially the same.
XSLT 2.0 how has two options on xsl:copy-of to control namespace behaviour.
copy-namespaces=yes|no determines whether all the inscope namespaces of an
element are copied when the element is copied. inherit-namespaces=yes|no
determines whether an element that's attached to a new parent inherits the
namespaces that are in scope for the new parent (the XPath data model,
following namepaces 1.1, doesn't require this.)
XQuery has recently introduced similar options, though at the level of the
query prolog rather than an individual copy operation.
It's not elegant - nothing to do with namespaces ever will be - but it
works.
Michael Kay
http://www.saxonica.com/
> -----Original Message-----
> From: Elliotte Harold [mailto:elharo AT metalab.unc.edu]
> Sent: 01 February 2005 00:58
> To: Michael Kay
> Cc: 'Wolfgang Hoschek'; 'xom-interest'
> Subject: Re: [XOM-interest] XPath Namespace Nodes rethink
>
> Michael Kay wrote:
>
>
> > Modelling "inscope namespaces" rather than "declared
> namespaces" gives much
> > more predictable results from a user perspective: when elements are
> > disconnected from a tree and added to another tree, they
> take all their
> > inscope namespaces with them.
>
> Consider what happens when you do this:
>
> Element a = new Element("pre:a", "http://www.example.com/");
> Element b = new Element("b", "http://www.example.org");
> a.appendChild(b);
>
> What namespaces are in scope for b now? Is the pre namespace
> mapped or
> not? The logical thing is to assume that, no, the pre prefix is
> undeclared, except you can't do that in XML 1.0.
>
> Now suppose we disconnect b and add it to c:
>
> b.detach();
> Element c = new Element("foo:c", "http://www.somewhere.com");
> c.appendChild(b);
>
> Does it still have the namespaces it had when it was attached
> to b? Does
> it lose all those namespaces when it's detached? If so, why? If not,
> what happens when you do this:
>
>
> b.detach();
> Element d = new Element("foo:d", "http://www.somewhere_else.com");
> d.appendChild(b);
>
> Now the foo prefix has been remapped, but only because it conflicted.
> Otherwise it wouldn't have been.
>
> No matter how you slice it, you end up with these weird corner cases.
> XSLT, XPath, and DOM work with this, barely, because they
> never move a
> node from one document to another. They create new nodes, but don't
> rearrange existing nodes. That causes problems and limitations of its
> own. XOM does move nodes from one document to another, and in
> so doing
> bends XML namespaces just far enough to break them.
>
> --
> Elliotte Rusty Harold elharo AT metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/
ref=nosim
>
- RE: [XOM-interest] XPath Namespace Nodes rethink, Michael Kay, 02/01/2005
Archive powered by MHonArc 2.6.24.