Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Exclusive Canonicalizer

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Exclusive Canonicalizer
  • Date: Mon, 24 Jan 2005 16:35:58 -0800


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]





Archive powered by MHonArc 2.6.24.

Top of Page