Glen Daniels wrote:
Hi folks:
The second choice wouldn't be element.getNamespace(), it would be
the default namepace. Both choices are valid depending on context,
which is why I believe there was a switch on the Axis1 version of
this logic (something like "enableDefaultNS" or something).
Recommend a switch, and default to doing default namespace logic. So:
I disagree .. if you resolve a QName in the context of an element and if
the QName has no prefix then it must still be resolved as a qualified
name - thereby inheriting the default NS. That's what a QName of an attr
or an element resolved in the context of an element; so why should
QNames in content (attribute value or text value) be different?
So I'm -1 for adding two forms of this.
Sanjiva.
What does XSD say in this regard? things like XmlBeans have a qname
type, so they must implement something. I'd hate to do something
inconsistent from everything else.
IIRC, there are different interpretations for different usages/specs
(XPath, XQuery, Schema, etc.), but it might be that this has been
cleaned up by now and is more consistent. We needed the option for Axis 1.
We could certainly do the default-ns version now and add a
non-defaulting version later if needed.
Right. I've stuck the code in with both. However, we could pull the
option to choose your action from the OMElement interface (and test),
then make the method private so the public operation only gives you what
we decide is appropriate. If nobody objects, that is what I will do.
-steve
- Re: [Axis2] Qnames Steve Loughran
-