Carsten --
This is discussed in
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces-Considerations
In particular, "Note that because the DOM does no lexical checking, the
empty string will be treated as a real namespace URI in DOM Level 2
methods. Applications must use the value null as the namespaceURI
parameter for methods if they wish to have no namespace."
Change your getAttributeNS call to getAttributeNS(null, "name") and see
what happens.
Gary
Carsten Ziegeler wrote:
>
> Hi Gary,
>
> just a quick question to very things:
>
> We changed now all methods to their equivalents with the ending "NS".
> If we now want to retrieve an attribute which has no namespace,
> we use the element method "getAttributeNS("", "name"). However
> this returns the empty string whereas "getAttribute("name") works.
>
> Is this a bug in the getAttributeNS() method? I read (now) the
> dom level 2 spec about this, but I think it is now very clear
> about this point:
>
> >>>>
> getAttributeNS introduced in DOM Level 2
> Retrieves an attribute value by local name and namespace URI. HTML-only DOM
> implementations do not need to implement this method.
> Parameters
> namespaceURI of type DOMString
> The namespace URI of the attribute to retrieve.
>
> localName of type DOMString
> The local name of the attribute to retrieve.
>
> Return Value
> DOMString
> The Attr value as a string, or the empty string if that attribute does not
> have a specified or default value.
>
> No Exceptions
> <<<<<
>
> Carsten
>
> > -----Ursprungliche Nachricht-----
> > Von: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> > Gesendet: Mittwoch, 11. Juli 2001 10:09
> > An: [EMAIL PROTECTED]
> > Betreff: Re: AW: [Xalan-J 2.2.0D6]: Strange problems with DOM and XPath
> >
> >
> > Carsten --
> >
> > I'm not claiming that it is -not- a bug in XalanJ2. I'm just suggesting
> > that if the DOM stuff gets cleaned up and the bug is still there, we'll
> > look for it.
> >
> > Gary
> >
> > Carsten Ziegeler wrote:
> > >
> > > Hi Gary,
> > >
> > > sorry for blaming Xalan-J again for a not existing bug. Our developers
> > > should really read the DOM spec first...(our should do it...)
> > >
> > > But thank you for this hint, we are currently rewriting our applications
> > > and will test it over the next days.
> > >
> > > Regards
> > >
> > > Carsten
> > >
> > > > -----Ursprungliche Nachricht-----
> > > > Von: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> > > > Gesendet: Dienstag, 10. Juli 2001 20:49
> > > > An: [EMAIL PROTECTED]
> > > > Betreff: Re: AW: [Xalan-J 2.2.0D6]: Strange problems with DOM
> > and XPath
> > > >
> > > >
> > > > Carsten --
> > > >
> > > > I deserialized your attachment and noticed that it mixes DOM Level 1
> > > > nodes (ElementImpl) with Level 2 nodes (ElementNSImpl). Since things
> > > > work when you serialize and then reparse, I suspect that
> > DOM2DTM is not
> > > > handling this situation as you expect. The DOM spec does say "mixing
> > > > both sets of methods can lead to unpredictable results" and it seems
> > > > like that is what's happening.
> > > >
> > > > If possible, try to rewrite your application so that you are
> > using only
> > > > the NS forms of the various DOM APIs and then see if you can reproduce
> > > > your problem.
> > > >
> > > > Gary
> > > >
> > > > Carsten Ziegeler wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I know that it is hard to find but I have absolutely no clue how
> > > > > to build a test case.
> > > > >
> > > > > I know do the following: If the XPathAPI throws this NPE, I catch
> > > > > the exception, serialize the complete document to a string and
> > > > > then reparse it, creating a clean DOM and invoke then the
> > > > > XPathAPI again. And this works.
> > > > >
> > > > > I serialized the document and attached it to the mail. I hope
> > > > > this helps you.
> > > > >
> > > > > (I didn't test if it is reproducable by deserialization).
> > > > >
> > > > > Regards,
> > > > >
> > > > > Carsten
> > > > >
> > > > > Open Source Group sunShine - b:Integrated
> > > > > ================================================================
> > > > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > > > www.sundn.de mailto: [EMAIL PROTECTED]
> > > > > ================================================================
> > > > >
> > > > > > -----Ursprungliche Nachricht-----
> > > > > > Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> > > > > Gesendet: Freitag, 6. Juli 2001 15:31
> > > > > An: [EMAIL PROTECTED]
> > > > > Betreff: Re: [Xalan-J 2.2.0D6]: Strange problems with DOM and XPath
> > > > >
> > > > >
> > > > >
> > > > > The problem is happening during incremental construction of
> > > the DTM model.
> > > > > It's trying to retrieve information which has not yet been stored,
> > > > > specifically, the expanded type information for a node which
> > > hasn't yet
> > > > > been written into the tables. But unless we can provoke it under a
> > > > > debugger, I really can't tell whether this is because it's
> > > referencing a
> > > > > node that hasn't yet been created, or a node which has been
> > > > > created but not
> > > > > initialized properly. Neither, of course, should be happening.
> > > > >
> > > > > I've got one off-the-cuff guess... The DOM permits using
> > > > > namespaces without
> > > > > ever declaring them. It's possible that you're creating this
> > > > > situation, and
> > > > > that our DOM2DTM code isn't handling it properly. We could try a few
> > > > > examples and see if we can reproduce the problem that way...
> > > > >
> > > > > ... but if there's any way you can come up with a reliably
> > > reproducable
> > > > > testcase -- maybe add code to catch that exception and
> > > serialize out the
> > > > > DOM which is provoking it, though serializing might wind up
> > > masking the
> > > > > problem? -- that'd be tremendously helpful.
> > > > >
