You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Paul Millar (JIRA)" <ji...@apache.org> on 2012/11/14 10:26:12 UTC

[jira] [Commented] (AXIOM-441) Unable to parse XML with empty default namespace attribute value with OpenJDK StAX implementation

    [ https://issues.apache.org/jira/browse/AXIOM-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496971#comment-13496971 ] 

Paul Millar commented on AXIOM-441:
-----------------------------------

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