As to part 1 of your response: To clarify - i never intended to state and/or imply that a Document MUST be passed -- only that the behavior you are expecting is accomplished by passing a Node that is a Document node. My sole intent was to answer your original question "Can somebody explain me why this is so?" Sorry if my answer was not helpful to the original question you posed
----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Dave Flanagan" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[email protected]> Sent: Thursday, August 28, 2003 10:23 AM Subject: Re: unexpected behaviour processing a branch with DOM Hello, Dave Thank you for remembering me of the naming conventions, this was my first post to this list. I understand the peculiarities of XSLT regarding the root and document elements, however this does not seem to be the case here. I think Xalan is not showing a compliant behaviour. (I therefore have posted this note also on the xalan-dev list. I don't know if it will pass through the spam filters.) Two reasons why I think Xalan is not complying: 1) The constructor DOMSource(Node) does *not* require a Document or a DocumentFragment, neither does any other constructor: it works a simple Node. Not only there are no stated restrictions, there is a explicit assurance that any node with a subtree sufices. Quoting the javadocs: public DOMSource(org.w3c.dom.Node n) Create a new input source with a DOM node. The operation will be applied to the subtree rooted at this node. In XSLT, a "/" pattern still means the root of the tree (not the subtree), and the evaluation of global variables and parameters is done from the root node also. [ <== !!! ] Parameters:n - The DOM node that will contain the Source tree. As written, any Node should work as a root node, since it is the subtree that is processed. Xalan should call the "/" template whatever the type of the "root" node. Where did you read it *must* be a Document[Fragment] ? 2) It is very strange that the root template was not called but the DE (document element) template was! The responsability of calling the DE template is of the <apply-templates> inside the root template. This is odd. It seems the Xalan is wrongly using the node's child (the DE) instead of the node itself (the root). This can be seen if instead of DOMSource xml = new DOMSource( base.getParentNode() ); you write DOMSource xml = new DOMSource( base ); The result should not be the same, since the subtrees are different, but Xalan produces the same result! Odd, very odd. I see not reason to limit the node type to Document[Fragment]. Any node with a subtree should suffice. Maybe Xalan has internal reasons to do this, probably something to do with some document-related information (systemID?) beeing stored in the Document object instead of a Node. But DOMSource behaviour should not be affected. Or did I miss something? ============================================= Marcelo Jaccoud Amaral Petrobras - TI - Neg�cios Eletr�nicos mailto:jaccoud [at] petrobras.com.br voice: +55 21 2534-3485 fax: +55 21 2534-1809 ============================================= There are only 10 kinds of people in the world: those who understand binary and those who don't. Dave Flanagan <[EMAIL PROTECTED] Para: [EMAIL PROTECTED] ngetc.com> cc: (cco: Marcelo Jaccoud Amaral/RJ/Petrobras) Assunto: Re: unexpected behaviour processing a branch with 2003-08-28 00:38 DOM Hello jaccoud, In order to attempt to clarify what you are seeing I am going to start by trying to convince you to be very careful of your use of the word "root" when speaking about XML. I do this because I have seen it time and time again be used in such a way that it leads to automatic confusion when speaking of XSLT in my experience. Many people refer to the first Element in an XML document as the "root element" of the XML document. When an element is described as a node, these same people then naturally begin to think of this first element as the root node, and then begin to think of "/" as representing the first element inside of an XML document. To avoid this confusion it may be better to only ever refer to the first element within an XML document as the "document element", and ONLY use the term "root" to refer to the "/" used within a memory based model such as the DOM or XSLT's tree model. With this said - in a DOM structure - the "root" can be thought of as equivalent to an object of type org.w3.dom.Document in the DOM. The first element in the XML document is actually a child node of the Document. So if the Node being passed to the DOMSource constructor is NOT a Document object the node being passed to the stylesheet via the transform method will NEVER be processed by the <xsl:template match="/"> element in your stylesheet. The reason your last test worked with a DocumentFragment is because - as is stated in the javadocs: DocumentFragment is a "lightweight" or "minimal" Document object So it IS treated as if it were a Document and therefore would match "/". If in your first example Element base was equal to the "document element" then base.getParentNode() would have been the Document object and "/" would have been matched in your stylesheet. You wrote: Element base = ... (find the element which is to be used as the root); DOMSource xml = new DOMSource( base.getParentNode() ); I will use a sample XML document shown below to try to walk you through what you are seeing happen: <?xml version="1.0"?> <library> <book> <title>A Title</title> </book> </library> If Element base were to be the "title" node shown above then the book node would have been the parameter passed to the DOMSource constructor since you called the getParentNode on title So your when the transform takes place the "book" node is a single node in the node set that is made available for processing by the stylesheet. Because of this it would be handled by a template matching "book" instead of what you may have expected - a template that matches "/". so your base is not a child of the Document object but merely the child of an Element that is basically a descendant of the Document. Hope I explained in such a way that it makes sense just remeber to be careful not to think of the first element as the "root" and don't think of "/" as the first element. If you think of "/" as a Document object it may help clear up some confusion Dave Flanagan Wednesday, August 27, 2003, 3:50:15 PM, you wrote: jpcb> Hi. jpcb> I have a issue with the DOM processing and couldn't find related topics in jpcb> the archives. Perhaps someone could provide some help. jpcb> As part a web service (I use Axis), I am extracting a branch of the SOAP jpcb> body and using it as input to Xalan. jpcb> I am using a DOMSource initialized with my root element parent node, as jpcb> required by DOMSource's constructor. It lloks like this: jpcb> Element base = ... (find the element which is to be used as the jpcb> root); jpcb> DOMSource xml = new DOMSource( base.getParentNode() ); jpcb> base's parent node is a simple element, whith a single child, base itself. jpcb> The transformation runned smothly, but the results showed the although the jpcb> base element was correctly matched and processed, the template matching "/" jpcb> was not processed. According to DOMSource javadoc, it should have been. jpcb> I tried to use a new element instead of the actual parent, as in jpcb> Node fakeRoot = base.getOwnerDocument().createElement ("dummy"); jpcb> fakeRoot.appendChild(base); jpcb> DOMSource xml = new DOMSource( fakeRoot ); jpcb> The result was exactly the same: the "/" templated was not executed, its jpcb> child (the base element) was executed instead. In despair, a tried to usa a jpcb> DocumentFragment instead, as in: jpcb> Node fakeRoot = base.getOwnerDocument ().createDocumentFragment(); jpcb> fakeRoot.appendChild(base); jpcb> DOMSource xml = new DOMSource( fakeRoot ); jpcb> Now everything worked as expected, the "/" template was executed and the jpcb> output was OK. jpcb> Can somebody explain me why this is so? Shouldn't all three solutions jpcb> produce the same result? I'm trying to understand what I did wrong and why jpcb> only the third solution worked, because similar situations will appear in jpcb> other web services. jpcb> Thank in advance, jpcb> ============================================= jpcb> Marcelo Jaccoud Amaral jpcb> Petrobras - IT - e-business Division jpcb> mailto:jaccoud [at] petrobras.com.br jpcb> ============================================= jpcb> There are only 10 kinds of people in the world: those who understand binary jpcb> and those who don't.
