XInclude DOM2 problem [ was Xinclude problem. failed processing? Help! ]

[Kirk Woerner <ki...@stoneseeker.com>]

The problem with the document() function is the caching.  In the real case
scenario, the included document may be changed.  In fact, the END USER can
change the document, and it seems like document() caches all the friggin
time...

I think I actually figured out what may be happening.  I put a bunch of
println statements in XIncludeProcessor and found that in the scan and
scanForXInclude methods, it uses "getLocalName()" and "getNameSpaceURI()".
These both return null when scanning the node in question (even though
getNodeName returns "include") According to the spec, both of these are DOM
level 2 functions and

"For nodes of any type other than ELEMENT_NODE and ATTRIBUTE_NODE and nodes
created with a DOM Level 1 method, such as createElement from the Document
interface, this is always null."

Now, I'm not sure if that actually says what I think it says, but it I think
it says that getLocalName will always be null if the element was created
using a DOM level I function.  Might the XSL processor be using
"createElement from the Document interface?" to create these?  If so, what
do you think is the best way to scan for this?  I don't want to make the
change with no input from you but I'd be willing to "make it so" whatever
you think "it" may be :)

This has been redirected to dev list...


>-----Original Message-----
>From: Donald Ball [mailto:balld@webslingerZ.com]
>Sent: Monday, November 13, 2000 8:28 PM
>To: Cocoon-Users@Xml. Apache. Org
>Subject: RE: Xinclude problem. failed processing? Help!
>
>
>On Mon, 13 Nov 2000, Kirk Woerner wrote:
>
>> I did that.  Same symptoms.  As it shows below anyway, the XInclude
>> processor IS BEING CALLED.  It's just not doing anything.
>>
>> I think it's a bug.
>
>yep, it looks like you're exposing a bug. the only real difference between
>your page and the sample is that you are invoking the xslt processor
>before (and after) the xinclude processor. i haven't a clue (or the time)
>to track this down, sorry, but i'd love a patch. as a workaround, and
>possibly a superior solution in this instance, you might want to try using
>the xpath document function.
>
>- donald
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
>For additional commands, e-mail: cocoon-users-help@xml.apache.org
>