You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Donald Ball <ba...@webslingerZ.com> on 2000/11/15 06:27:43 UTC

Re: [C1][XInclude][PATCH] - XInclude DOM2 problem

On Tue, 14 Nov 2000, Kirk Woerner wrote:

> 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.

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.

oh, as far as lack of diff goes - your cvs client should be able to
produce a unified diff. please check and see - retyping patches by hand is
kinda frustrating.

- donald


RE: [C1][XInclude][PATCH] - XInclude DOM2 problem

Posted by Kirk Woerner <ki...@stoneseeker.com>.
um, I THINK that's what I'm saying.  It does seem a bit preposterous doesn't
it?  But it works (which is something:)  I also got an email from someone
else who had the same problem and same solution.  I'm not sure whether the
namespace info is lost.  I just know that using those NS functions don't
work and checking the attributes using getAttribute does work.  I actually
did look about in the Xalan code for some indication of how elements were
created but got confused and frustrated.  I understand the cocoon structure
pretty well from playing around in it, but not Xalan.

I actually didn't check the code out from CVS, just hacked the source that
came with 1.8.  I do have a CVS client though so I'll see what I can do...

>
>On Tue, 14 Nov 2000, Kirk Woerner wrote:
>
>> 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.
>
>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.
>
>oh, as far as lack of diff goes - your cvs client should be able to
>produce a unified diff. please check and see - retyping patches by hand is
>kinda frustrating.
>
>- donald
>