[
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: [email protected]
For additional commands, e-mail: [email protected]
