ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Millar (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AXIOM-441) Unable to parse XML with empty default namespace attribute value with OpenJDK StAX implementation
Date Wed, 14 Nov 2012 09:28:14 GMT

    [ 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


Mime
View raw message