XOM API for Processing XML with Java

[Steve Loughran <steve.loughran AT gmail.com>]

On 1/24/06, Elliotte Harold <elharo AT metalab.unc.edu> wrote:
> Steve Loughran wrote:
>
> > My particular need is this: I need to get a list of all currently
> > visible (prefix,namespace) tuples on an element so that I can then to
> > my own qname to element mapping, even after the node I was using has
> > been reparented.
>
> OK. That's one I haven't heard before, and I can see that. In the early
> days when we were hashing out the exact namespace model for XOM, one of
> the things we considered was maintaining all namespaces in scope when an
> element was deleted, but that was just too ugly. For instance, when an
> element node is inserted at a new position in the tree, does it
> undeclare all prefixes inherited from its ancestors?

no, it doesnt undeclare them, it should retain them for later use. Off
the record, I dont think the spec covers all the corner cases of
xmlns; it is only as I do my implementation and tests to go with that
I think of all the devious ways to break the system. If someone really
wants to play pathological xmlns games they are bound to break things.

>
> I tried to follow the principle of least surprise here based on my best
> guess of what most people would expect or want most of the time, but I'm
> afraid namespaces in XML are just too fundamentally weird to avoid
> surprising some of the people some of the time. Frankly if XOM can avoid
> surprising most of the people most of the time, it's doing really well. :-)
>
> I can see that the grid spec you're referring to uses namespaces in
> element content, but I still don't have a full use case. Why do you need
>   to move elements from one namespace scope to a different namespace
> scope? If you can explain that, you might convince me.

what we are really doing is creating a graph of things to deploy from
an XML document, with cross referencing and subclassing to avoid
duplication. Now, you shouldnt really have different namespace
declarations, but once you start importing docs from other places, its
going to happen.

if in one node you have this

  <login xmlns:t1="...">
    <user>stevo</user>
    <pass>secret</pass>
    <t1:something>value</t1:something>
  </login>

you can use it in different places

 <d:database>
  <login cdl:ref="../login" />
 </d:database>
 <server>
  <mydatabase extends="d:database">
    <pass>override</pass>
  </mydatabase>
  <user cdl:ref="mydatabase/user"/>
 </database>

the extends is a simple qname (only things at the top are extensible
templates), and is easy to process. But after extension you pull down
bits of the graph, to end up with a derivative work.


 <d:database>
   <login >
    <user>stevo</user>
    <pass>secret</pass>
    <t1:something xmlns:t1="...">value</t1:something>
   </login>
 </d:database>
 <server>
  <mydatabase>
   <login >
    <user>stevo</user>
    <pass>override</pass>
    <t1:something xmlns:t1="...">value</t1:something>
   </login>
  </mydatabase>
  <user>stevo</user>
 </database>

Actual deployment turns that into a graph of things that are deployed
across one or machines, and even then you can route xpath-like queries
round to get information of things. Caching the list of prefix
namespace pairs in scope at the time of parsing is the only sensible
way to manage the concept of scope at this point, where you have
definately left the world of xml documents, and instead just have a
mesh of java.rmi.Remote nodes that use QNames to identify themselves.

> Two more questions:
>
> 1. When you move an element from point A to point B does this happen
> during a depth first search from the root to the element you're moving?

I make a copy of the node then merge in the parent following some
rules (essentially: if the parent has a child of the same qname it
wins)

>
> 2. Do you just need all the namespaces when you detach, or do you also
> need them when you insert? This asks whether you allow a reinserted
> element to inherit namespaces from its new parent as well as its old.
> (Actually in XML 1.0 namespace prefixes can't be undeclared so the point
> is probably moot.)

That's an interesting question. Dont know. As I merge children I kind
of get both together. that bit all seems to work magically; its just
for reference resolution that I have to cache the table for later
abuse.

-steve