The definitive answer you may be looking for can be found in part 2 of the XPath 1.0 specification http://www.w3.org/TR/xpath#location-paths where it states: / selects the document root (which is always the parent of the document element)
Therefore it seems that Xalan works exactly as expected by the above statement. Hope this resolves your questions further. Dave Flanagan ----- Original Message ----- From: "Dave Flanagan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 28, 2003 1:47 PM Subject: Re: unexpected behaviour processing a branch with DOM > 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. > > > > > > > > >
