XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> > How about decoupling the exclusive Canonicalizer CVS from the XPath 
> > impl by having
>
> I haven't written the exclusive canonicalizer yet. Do you mean the 
> document subset canonicalizer?

ah, yep :-)

> > public final void write(Nodes nodes)
>
> It's possible, and indeed I originally planned to do it that way. 
> However, there are some tricky bits:
>
> 1. The Nodes argument can't contain nodes from multiple documents.

Throw an exception if that's detected.

> 2. The canonicalizer would have to sort the Nodes into document order 
> (doable)

Perhaps it's enough to just throw an exception if they aren't. But 
either way should work fine.

> 3. The canonicalizer would have to remove duplicates from the Nodes. 
> (doable)

Same as for 2)

> 4, I don't think the Nodes could be disconnected from a Document. I'm 
> not sure about this. Perhaps they could.

Probably.

> The real issue is that document subset canonicalization is defined in 
> terms of an XPath expression selecting a list of nodes from a 
> document. It is not defined in terms of an arbitrary list of nodes. 
> I'm worried that  there might be unexpected side effects if I attempt 
> to canonicalize just anything.

With the above issues addressed there shouldn't be any problems.

> Then again I can see good reasons to want to do this. Possibly I could 
> provide both options, but we'd need to consider what would happen with 
> arbitrary Nodes objects first.
>
> I also wonder if maybe passing a Nodes object should have different 
> semantics than passing in a document and an XPath expression that 
> selects those nodes. For instance, you might want to fully 
> canonicalize each node and all its descendants, attributes, and 
> namespaces rather than just the start-tags and end-tags you'd get with 
> an XPath expression that only selected those elements.

I guess different sematics would be confusing here. One important use 
for the method would be to swap the XPath impl., and so the same 
behaviour would be expected...

Wrt. document order (item 2): As the basic operation enabling easy 
document order checking, and hence sorting, you could have a XOM method 
to compare two nodes for document order. In the 
net.sf.saxon.xom.NodeWrapper we have a method for that. The algorithm 
is effective, but it's more complex than necessary because it delegates 
to an impl that's not XOM specific but rather object model agnostic. A 
XOM specific impl would be more desirable.

         * Determine the relative position of this node and another node, in
         * document order. The other node will always be in the same document.
         *
         * @param other
	 *            The other node, whose position is to be compared with 
this
         *            node
	 * @return -1 if this node precedes the other node, +1 if it follows 
the
         *         other node, or 0 if they are the same node. (In this case,
         *         isSameNode() will always return true, and the two nodes 
will
         *         produce the same result for generateId())
         */
        public int compareOrder(Node other) {

[You could throw an exception if the nodes are not from the same 
document]