ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George I Matkovits <matkovi...@uswest.net>
Subject Re: Fw: Xerces 1.1.2 Bug
Date Sun, 23 Jul 2000 16:36:36 GMT
There is also amother slight problem. Xerces1.1.2 is not really backward
compatible with Xerces1.0.3 and Cocoon7.4 stops working. Is this a xerces or
Cocoon bug? IMHO even Java XML code should be backward compatible? (-:
Regards - George

duftler@us.ibm.com wrote:

> I agree with you. My comment(s) had nothing to do with the DOM spec. (I
> realize that some of my comments taken alone don't indicate this, but the
> thread is about a bug in Xerces.) I was saying that Xerces' behavior is
> inconsistent with Xerces' documentation. Either way it's a Xerces bug that
> should be fixed, regardless of what the DOM spec says.
>
> And, we should do what you and Joe suggest, which is to use
> getAttributeNodeNS in the same manner we use getAttribute. And I think Joe
> has clarified what the spec says. ;-)
>
> -Matt
>
> "Steven McDowall" <sjm@aptest.com> on 07/19/2000 04:58:13 PM
>
> Please respond to soap-dev@xml.apache.org
>
> To:   <soap-dev@xml.apache.org>
> cc:
> Subject:  RE: Fw: Xerces 1.1.2 Bug
>
> Somehow I get the feeling that if the DOM 2 Spec says one thing, but the
> API
> Doc
> indicates a different behavior, the API Doc is going to change to reflect
> what the
> DOM SPec says (and what it actually does), and not vice-versa.. :-(
>
> Thus, although there does appear to be a "bug", the bug is probably a
> documentation
> bug and not implementation .. My gut feeling is it is probably better to
> just bite
> the bullet and use getAttributeNS as Joseph suggests with a little wrapper
> that first
> tries to getAttributeNodeNS, etc.
>
> THen go back to xerces 1.1.2 ..
>
> Just MY opinion though.. Would be nice to get absolute clarification from
> the xerces
> people what they indeed to do .. change the doc or implementation ..
>
> -Steve
>
> -----Original Message-----
> From: duftler@us.ibm.com [mailto:duftler@us.ibm.com]
> Sent: Wednesday, July 19, 2000 9:03 AM
> To: soap-user@xml.apache.org
> Cc: Sanjiva Weerawarana; mpogue@us.ibm.com; andyc@us.ibm.com;
> soap-dev@xml.apache.org; soap-user@xml.apache.org; keshlam@us.ibm.com
> Subject: Re: Fw: Xerces 1.1.2 Bug
>
> >The DOM's getAttributeNS() method behaves like getAttribute().
>
> Not according to the apiDocs. They state that the exact opposite is true.
> When I said it was a bug, I meant as per the api docs that accompany the
> distribution. I believe this is what the other folks who encountered this
> meant also. The following is from the apiDocs for
> Element.getAttributeNS(...).
>
> getAttributeNS
>
> public java.lang.String getAttributeNS(java.lang.String namespaceURI,
>                                        java.lang.String localName)
>
>      Retrieves an attribute value by local name and namespace URI.
> HTML-only DOM implementations do not need to implement this method.
>      Parameters:
>           namespaceURI - The namespace URI of the attribute to retrieve.
>           localName - The local name of the attribute to retrieve.
>      Returns:
>           The Attr value as a string, or an null if that attribute does not
> have a specified or default value. This is different from getAttribute
> which never return null .
>      Since:
>           DOM Level 2
>
> Joseph Kesselman/Watson/IBM@IBMUS on 07/19/2000 09:00:48 AM
>
> Please respond to soap-user@xml.apache.org
>
> To:   "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
> cc:   Mike Pogue/Cupertino/IBM@IBMUS, Matthew Duftler/Watson/IBM@IBMUS,
>       Andy Clark/Austin/Contr/IBM@IBMUS, soap-dev@xml.apache.org,
>       soap-user@xml.apache.org
> Subject:  Re: Fw: Xerces 1.1.2 Bug
>
> The described behavior is not a bug, per the DOM Level 2 Candidate
> Recommendation.
>
> The DOM's getAttributeNS() method behaves like getAttribute(). If an
> attribute is not present and doesn't have a default value, it should return
> an empty string.
>
> If you want to distinguish this case, use getAttributeNodeNS() to obtain
> the Attr object; this returns null if there isn't one.
>
> You can obtain the requested behavior by saying something like:
>
>      Attr tempAttr;
>      String valueOrNull = ( (tempAttr=myNode.getAttributeNodeNS(...)) ==
> null )
>                : null
>                ? tempAttr.getNodeValue();
>
> (We can, and do, argue about whether having getAttribute return an empty
> string was a good idea or not. But that decision was made in DOM Level 1,
> and we decided that the new namespace-aware methods in Level 2 should
> follow that behavior to avoid confusing users faimilar with the Level 1
> calls.)
>
> ______________________________________
> Joe Kesselman  / IBM Research


Mime
View raw message