cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirk Woerner" <k...@stoneseeker.com>
Subject RE: [C1.8.2] xinclude after xsp not working
Date Wed, 31 Jan 2001 06:28:57 GMT
This from the original back and forth on this issue

Kirk Woerner
>
> This is a little ugly, but it works and I think it's valid.  The bug
> appears when attempting to process xinclude elements that were generated
> from a stylesheet.  The DOM nodes generated from within xsl are apparently
> not DOM II so the checks for "getAttributeNS()" in scanForXInclude() do
> not work when they should.

Donald Ball
>
>woah - just so i'm sure we're on the same level here - you're saying that
>when a page has been generated by the XSLT processor, the namespace URI
>information is lost, so the scanForXInclude method fails because it can't
>find the attributes href and parse in the xinclude namespace? and your
>suggested workaround is to look for attributes named xinclude:href
>instead? hmm. i don't like it, but i can't see any alternative - but it
>strikes me as _very_ strange that DOMs generated by Xalan aren't DOM2
>compliant. Scott, any other xalan people, can y'all verify that this is or
>is not the case? we're talking xalan-1.2 here i reckon.

-------------------------------

From
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html

<quote>
Note: DOM Level 1 methods are namespace ignorant. Therefore, while it is
safe to use these methods when not dealing with namespaces, using them and
the new ones at the same time should be avoided. DOM Level 1 methods solely
identify attribute nodes by their nodeName. On the contrary, the DOM Level 2
methods related to namespaces, identify attribute nodes by their
namespaceURI and localName. Because of this fundamental difference, mixing
both sets of methods can lead to unpredictable results. In particular, using
setAttributeNS, an element may have two attributes (or more) that have the
same nodeName, but different namespaceURIs. Calling getAttribute with that
nodeName could then return any of those attributes. The result depends on
the implementation. Similarly, using setAttributeNode, one can set two
attributes (or more) that have different nodeNames but the same prefix and
namespaceURI. In this case getAttributeNodeNS will return either attribute,
in an implementation dependent manner. The only guarantee in such cases is
that all methods that access a named item by its nodeName will access the
same item, and all methods which access a node by its URI and local name
will access the same node. For instance, setAttribute and setAttributeNS
affect the node that getAttribute and getAttributeNS, respectively, return.
</quote>

What this along with the behavior of XInclude in scanXInclude tells me is
that Xalan is probably creating attributes using setAttribute somewhere.
This creates an attribute named "xinclude:href" as opposed to an attribute
with a namespace of "xinclude" and a local name of "href".  The patch we put
in is a cludge since I couldn't find where in Xalan the nodes get created...


Mime
View raw message