[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlrpc-user
Subject: [jira] [Comment Edited] (AXIOM-441) Unable to parse XML with empty default namespace attribute value
From: "Paul Millar (JIRA)" <jira () apache ! org>
Date: 2012-11-14 9:28:14
Message-ID: 1419578830.113150.1352885294198.JavaMail.jiratomcat () arcas
[Download RAW message or body]
[ https://issues.apache.org/jira/browse/AXIOM-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496971#comment-13496971 \
]
Paul Millar edited comment on AXIOM-441 at 11/14/12 9:27 AM:
-------------------------------------------------------------
Hi Andreas,
Sorry, I must confess to being increasingly confused by all this.
I was wrong when I said the JavaDoc is "clear that this method may return null". I \
was mistakenly looking at the nullary getNamespaceURI. However, this method is *not* \
used by the StAXOMBuilder#processNamespaceData method. Instead, the unary \
getNamespaceURI(int) is used.
The Oracle JavaDoc for the getNamespaceURI(int) method:
http://docs.oracle.com/javaee/5/api/javax/xml/stream/XMLStreamReader.html#getNamespaceURI%28int%29
and Woodstox JavaDoc for this method:
http://woodstox.codehaus.org/javadoc/stax-api/1.0/javax/xml/stream/XMLStreamReader.html#getNamespaceURI%28int%29
are basically identical and say only that this method "returns the namespace uri". \
There is no description of how an element with no default namespace is represented.
The problem is that Woodstox and SJSXP (used by OpenJDK 6 and OpenJDK 7) have \
adopting different ways of representing this situation and the JavaDoc does not make \
it clear which is correct.
Given there is a reference implementation, I looked at how this code-base handles the \
situation. My reading of the source-code is that getNamespaceURI will return null \
for an element without a namespace:
http://svn.stax.codehaus.org/browse/stax/trunk/dev/src/com/bea/xml/stream/MXParser.java?hb=true#to2705
Therefore, one could argue that Woodstox is buggy for returning a non-null string in \
this case.
In all this, there is considerable ambiguity. This seems to be true for other \
methods in XMLStreamReader (e.g., on a START_ELEMENT event for an element with no \
prefix, should the nullary getNamespaceURI return the default namespace or null? The \
JavaDoc says it should do both)
It's not clear to me where I should report these problems but, as a standard, StAX \
seems to have some issues.
Thanks for committing the patch (or trying to, "Result = ABORTED" sounds ominous). I \
agree that allowing Axiom test suite to run against non-Woodstox StAX implementation \
is a good idea. In the absence of a StAX conformity suite, it's Axiom's best bet.
HTH,
Paul.
was (Author: paulmillar):
Hi Andreas,
Sorry, I must confess to being increasingly confused by all this.
I was wrong when I said the JavaDoc is "clear that this method may return null". I \
was mistakenly looking at the nullary getNamespaceURI. However, this method is *not* \
used by the StAXOMBuilder#processNamespaceData method. Instead, the unary \
getNamespaceURI(int) is used.
The Oracle JavaDoc for the getNamespaceURI(int) method:
http://docs.oracle.com/javaee/5/api/javax/xml/stream/XMLStreamReader.html#getNamespaceURI%28int%29
and Woodstox JavaDoc for this method:
http://woodstox.codehaus.org/javadoc/stax-api/1.0/javax/xml/stream/XMLStreamReader.html#getNamespaceURI%28int%29
are basically identical and say only that this method "returns the namespace uri". \
There is no description of how an element with no default namespace is represented.
The problem is that Woodstox and SJSXP (used by OpenJDK 6 and OpenJDK 7) have \
adopting different ways of representing this situation and the JavaDoc does not make \
it clear which is correct.
Given there is a reference implementation, I looked at how this code-base handles the \
situation. My reading of the source-code is that getNamespaceURI will return null \
for an element without a namespace:
http://svn.stax.codehaus.org/browse/stax/trunk/dev/src/com/bea/xml/stream/MXParser.java?hb=true#to2705
Therefore, one could argue that Woodstox is buggy for returning a non-null string in \
this case.
In all this, there is considerable ambiguity. This seems to be true for other \
methods in XMLStreamReader (e.g., on a START_ELEMENT event for an element with no \
prefix, should the nullary getNamespaceURI return the default namespace or null? The \
JavaDoc says it should do both)
It's not clear to me where I should report these problems but, as a standard, StAX \
seems to have some issues.
Thanks for committing the patch (or trying to ("Result = ABORTED" sounds ominous). I \
agree that allowing Axiom test suite to run against non-Woodstox StAX implementation \
is a good idea. In the absence of a StAX conformity suite, it's Axiom's best bet.
HTH,
Paul.
> Unable to parse XML with empty default namespace attribute value with OpenJDK StAX \
> implementation
> -------------------------------------------------------------------------------------------------
>
> Key: AXIOM-441
> URL: https://issues.apache.org/jira/browse/AXIOM-441
> Project: Axiom
> Issue Type: Bug
> Components: API, LLOM
> Affects Versions: 1.2.13
> Reporter: Paul Millar
> Assignee: Andreas Veithen
> Labels: patch
> Fix For: 1.2.14
>
> Attachments: patch-fix-StAXOMBuilder.diff
>
>
> From:
> http://www.w3.org/TR/2009/REC-xml-names-20091208/
> "The attribute value in a default namespace declaration MAY be empty. This has the \
> same effect, within the scope of the declaration, of there being no default \
> namespace." Here is a document that demonstrates this:
> <?xml version='1.0' encoding='UTF-8'?>
> <foo xmlns='http://example.org/'>
> <bar xmlns=''>value</bar>
> </foo>
> The following code snippet (slightly modified from Axiom documentation) uses Axiom \
> to parse a String variable xmlData: InputStream in =
> new ByteArrayInputStream(xmlData.getBytes(Charset.forName("UTF-8")));
> OMXMLParserWrapper builder = OMXMLBuilderFactory.createOMBuilder(in);
> OMElement documentElement = builder.getDocumentElement();
> documentElement.serialize(System.out);
> System.out.println();
> When given the above XML example, an IllegalArgumentException is thrown:
> Exception in thread "main" java.lang.IllegalArgumentException: Namespace URI may \
> not be null at org.apache.axiom.om.impl.llom.OMNamespaceImpl.<init>(OMNamespaceImpl.java:38)
> at org.apache.axiom.om.impl.llom.OMElementImpl.addNamespaceDeclaration(OMElementImpl.java:430)
> at org.apache.axiom.om.impl.builder.StAXOMBuilder.processNamespaceData(StAXOMBuilder.java:608)
> at org.apache.axiom.om.impl.builder.StAXOMBuilder.populateOMElement(StAXOMBuilder.java:430)
> at org.apache.axiom.om.impl.builder.StAXOMBuilder.createOMElement(StAXOMBuilder.java:461)
> at org.apache.axiom.om.impl.builder.StAXOMBuilder.createNextOMElement(StAXOMBuilder.java:318)
> at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:249)
> at org.apache.axiom.om.impl.llom.OMElementImpl.buildNext(OMElementImpl.java:709)
> at org.apache.axiom.om.impl.llom.OMNodeImpl.getNextOMSibling(OMNodeImpl.java:121)
> at org.apache.axiom.om.impl.traverse.OMChildrenIterator.getNextNode(OMChildrenIterator.java:36)
> at org.apache.axiom.om.impl.traverse.OMAbstractIterator.hasNext(OMAbstractIterator.java:69)
> at org.apache.axiom.om.impl.util.OMSerializerUtil.serializeChildren(OMSerializerUtil.java:555)
> at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:846)
> at org.apache.axiom.om.impl.llom.OMSerializableImpl.serialize(OMSerializableImpl.java:120)
> at org.apache.axiom.om.impl.llom.OMSerializableImpl.serialize(OMSerializableImpl.java:108)
> at org.apache.axiom.om.impl.llom.OMSerializableImpl.serialize(OMSerializableImpl.java:127)
> This looks like a bug.
> Cheers,
> Paul.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic