Thanks for the fast answer.

I could certainly arrange to return a node still connected to the original tree, at least in some cases. The document fragment comes at least partly from efforts to make it stop finding the entire document. However, I have other use cases where I'm essentially synthesizing a collection of sibling nodes on the fly to return to the caller. That's another reason I was using the DocumentFragment.
My current workaround is to create a whole new Document containing just a newly created subtree, but it's not very efficient.
Of course, now that I realize that saxon is taking the DOM and regenerating SAX events, I might just as well do the same thing myself.

Regards,

Karen Lease
Senior Software Developer
Karen.Lease@vftis.spx.com
Direct: +33 (0)1 4196 2805
-----------------------------------------------------------------------------------------
SPX Valley Forge - Technical Information Services
147 avenue Paul Doumer - 92500 Rueil Malmaison - France
Tel : +33 (0)1 41 96 28 00 - Fax : +33 (0)1 41 96 28 01
----------------------------------------------------------------------------------------
The information contained in this electronic mail transmission is intended by SPX Corporation for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged.  If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or call the SPX Help Desk at 215-293-2811 so that the sender's address records can be corrected.



<michael.h.kay@ntlworld.com>

01/15/2003 09:27 AM

       
        To:        Karen.Lease@VFTIS.spx.com, saxon-help@lists.sourceforge.net
        cc:        
        Subject:        Re: [saxon] Bug when URIResolver returns DOMSource with non Document node



I need to think more carefully about what the behavior should be in this case. Your code appears to be returning a copy of the subtree rooted at the selected node. Generally I've followed what Microsoft did (they were the ones who introduced the idea of starting a transformation at a node other than the root), which is that the start node is not detached from the tree it belonged to - you can still do ancestor::x to find its original ancestors.

Michael Kay
>
> From: Karen.Lease@VFTIS.spx.com
> Date: 2003/01/14 Tue PM 02:31:14 GMT
> To: saxon-help@lists.sourceforge.net
> Subject: [saxon] Bug when URIResolver returns DOMSource with non Document node
>
> Hi list,
> I believe that the known bug 548228, "Identity transform of DOM subtree" also affects the URIResolver when a
> DOMSource which starts at a node which is not the Document node is
> returned. The result is that the entire DOM tree rather than the actual
> Node given to the DOMSource is returned.
> From looking at the Saxon DOMDriver class, this bug is simple to fix; in
> fact, the following trivial subclass which takes a DocumentFragment
> instead of a Document behaves as expected (well, at least as I expect).
>
> private static class DOMFragDriver extends com.icl.saxon.DOMDriver {
>     DOMFragDriver(Node root) {
>       super();
>       this.root = root;
>     }
>   }
>
> // Here is how it is used
>   private class SubtreeURIResolver implements URIResolver {
>     Document m_doc;
>     public Source resolve(String href, String base) throws
> TransformerException
>     {
>          // code to figure out the Node in the DOM which we want to return
>           Node retNode;
>           // Make a fragment
>           DocumentFragment docfrag = m_doc.createDocumentFragment();
>           docfrag.appendChild(retNode.cloneNode(true));
>           // This is what is happening inside SAXON to turn the DOMSource
> into a SAXSource
>           DOMFragDriver driver = new DOMFragDriver(docfrag);
>           SAXSource src = new SAXSource(driver, null);
>           src.setSystemId(href);
>           return src;
>       }
>   }
>
> Regards,
>
> Karen Lease
> Senior Software Developer
> Karen.Lease@vftis.spx.com
> Direct: +33 (0)1 4196 2805
> -----------------------------------------------------------------------------------------
> SPX Valley Forge - Technical Information Services
> 147 avenue Paul Doumer - 92500 Rueil Malmaison - France
> Tel : +33 (0)1 41 96 28 00 - Fax : +33 (0)1 41 96 28 01
> ----------------------------------------------------------------------------------------
> The information contained in this electronic mail transmission is intended
> by SPX Corporation for the use of the named individual or entity to which
> it is directed and may contain information that is confidential or
> privileged.  If you have received this electronic mail transmission in
> error, please delete it from your system without copying or forwarding it,
> and notify the sender of the error by reply email or call the SPX Help
> Desk at 215-293-2811 so that the sender's address records can be
> corrected.
>

Hi list,

I believe that the known bug 548228, "Identity transform of DOM subtree" also affects the URIResolver when a DOMSource which starts at a node which is not the Document node is returned. The result is that the entire DOM tree rather than the actual Node given to the DOMSource is returned.

From looking at the Saxon DOMDriver class, this bug is simple to fix; in fact, the following trivial subclass which takes a DocumentFragment instead of a Document behaves as expected (well, at least as I expect).


private static class DOMFragDriver extends com.icl.saxon.DOMDriver {

   DOMFragDriver(Node root) {

      super();
     this.root = root;

   }

 }


// Here is how it is used

 private class SubtreeURIResolver implements URIResolver {

   Document m_doc;

   public Source resolve(String href, String base) throws TransformerException

   {

        // code to figure out the Node in the DOM which we want to return

         Node retNode;

         // Make a fragment

         DocumentFragment docfrag = m_doc.createDocumentFragment();

         docfrag.appendChild(retNode.cloneNode(true));

         // This is what is happening inside SAXON to turn the DOMSource into a SAXSource

         DOMFragDriver driver = new DOMFragDriver(docfrag);

         SAXSource src = new SAXSource(driver, null);

         src.setSystemId(href);

         return src;

     }

 }


Regards,


Karen Lease
Senior Software Developer
Karen.Lease@vftis.spx.com
Direct: +33 (0)1 4196 2805
-----------------------------------------------------------------------------------------
SPX Valley Forge - Technical Information Services
147 avenue Paul Doumer - 92500 Rueil Malmaison - France
Tel : +33 (0)1 41 96 28 00 - Fax : +33 (0)1 41 96 28 01
----------------------------------------------------------------------------------------
The information contained in this electronic mail transmission is intended by SPX Corporation for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged.  If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or call the SPX Help Desk at 215-293-2811 so that the sender's address records can be corrected.