Re: cannot find the namespace declarations from an extension function
Adrian Herscu <[email protected]>
| Newsgroups | gmane.text.xml.xalan.java.user |
|---|---|
| Message-ID | <[email protected]> |
The original issue was that the Xerces code (from
http://svn.apache.org/viewvc/xalan/java/trunk/src/org/apache/xml/dtm/ref/DTMNodeProxy.java?view=markup)
public String lookupNamespaceURI(String specifiedPrefix) {
short type = this.getNodeType();
switch (type) {
case Node.ELEMENT_NODE : {
String namespace = this.getNamespaceURI();
String prefix = this.getPrefix();
if (namespace !=null) {
// REVISIT: is it possible that prefix is empty string?
if (specifiedPrefix== null &&
prefix==specifiedPrefix) {
// looking for default namespace
return namespace;
} else if (prefix != null &&
prefix.equals(specifiedPrefix)) {
// non default namespace
return namespace;
}
}
if (this.hasAttributes()) {
NamedNodeMap map = this.getAttributes();
int length = map.getLength();
for (int i=0;i<length;i++) {
Node attr = map.item(i);
String attrPrefix = attr.getPrefix();
String value = attr.getNodeValue();
namespace = attr.getNamespaceURI();
if (namespace !=null &&
namespace.equals("http://www.w3.org/2000/xmlns/")) {
// at this point we are dealing with DOM
Level 2 nodes only
if (specifiedPrefix == null &&
attr.getNodeName().equals("xmlns")) {
// default namespace
return value;
} else if (attrPrefix !=null &&
attrPrefix.equals("xmlns") &&
attr.getLocalName().equals(specifiedPrefix)) {
// non default namespace
return value;
}
}
}
}
threats it's document storage model as a DOM -- for example:
attr.getNodeName().equals("xmlns")), where attr = map.item(i) and
map = this.getAttributes() and this implements the DOM Node interface;
simply said, nodes have attributes and one of may have an attribute
named "xmlns".
Hence, there is mismatch between the data storage layer and the data
access layer, because such nodes are never returned by the data storage
layer, eventually causing a soft exception (the lookupNamespaceURI
method returns null) while there is a matching namespace declaration.
Adrian.
[email protected] wrote:
>>> But on this list the view should probably be Xalan, hence XSLT and the
>>> XPath Data Model. A namespace declaration attribute isn't an attribute
>>> in XDM, because it's not on the attribute axis. The fact that
> namespace
>>> declaration serialization happens to take attribute form doesn't
> matter.
>>>>> That's why it doesn't show up among the attributes, neither in DOM
>>>>> nor in XDM (XPath Data Model).
>> Seems like XDM is related to XPath 2.0.
>
> And XSLT/XQuery, which also use the XPath data model. The XPath 2.0 data
> model is derived from the XPath 1.0 data model, which as you said is
> described at
>
>> http://www.w3.org/TR/xpath#data-model
>
>> * for an xmlns attribute, if the element or some ancestor has an
>> xmlns attribute, and the value of the xmlns attribute for the nearest
>> such element is non-empty
>>
>> They are called "attributes"!
>
> They are attributes in the XML syntax sense. They are not Attribute Nodes
> in the XPath 1.0 data model; they are Namespace Nodes. And actually, one
> of the changes in the 2.0 model is that namespace declarations need not
> appear as nodes at all, but just as values that can be retrieved from a
> node; the 1.0 description of "namespace nodes" has some warts and is being
> phased out.
>
>> Also in DOM2 Core there is nothing that suggests that "namespace
>> attributes" are not just regular attributes.
>>
>>> So I guess DOM (which level?) requires them to show up.
>
> The DOM data models differs in a number of ways from the XPath data model;
> this is one of those differences. In the DOM, namespace declarations are
> indeed handled as attribute nodes... if they appear at all; the DOM
> considers them optional. (See DOM Level 3's discussion of its namespace
> normalization operation.)
>
> Sorry, but the DOM and XPath were tuned for slightly different
> requirements, and you're going to have to get used to working with these
> differences.
>
> (Admittedly, this is partly because the XML Infoset, which is the official
> description of what information in an XML document is
> available/meaningful, wasn't defined until well after the first release of
> DOM and XPath, and was deliberately left loose enough to accept both
> approaches. If we had the opportunity to do XML over again from scratch,
> the ideal thing would have been to define the Infoset -- including
> namespaces, schemas, base URIs, and all the other afterthoughts -- then
> define the syntax, then define all the tools and standards built on top of
> these. But that would have meant a much longer delay before XML became
> useful, and would probably have killed any chance for its adoption. Some
> day, a few decades from now, maybe we'll all have sufficient time to
> consider going back and doing a massive clean-up pass -- XML 2.0, akin to
> the ANSI C effort -- but XML's still growing too fast for that to be
> practical at this time.)
>