ws-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From R J Scheuerle Jr <sc...@us.ibm.com>
Subject Re: Stax parsers - one more variation
Date Tue, 28 Jul 2009 14:14:17 GMT

Hi Andreas,

I have not encountered any other parsers that have this interpretation.

Rich Scheuerle
Senior Programmer, IBM Web Services
Development, Support, and Open Source
Apache Axis2 (scheu@apache.org)
512-286-8420  (IBM TL 363-8420)


                                                                           
             Andreas Veithen                                               
             <andreas.veithen@                                             
             gmail.com>                                                 To 
                                       commons-dev@ws.apache.org           
             07/28/2009 09:09                                           cc 
             AM                                                            
                                                                   Subject 
                                       Re: Stax parsers - one more         
             Please respond to         variation                           
             commons-dev@ws.ap                                             
                 ache.org                                                  
                                                                           
                                                                           
                                                                           
                                                                           




Rich,

Are there any other "user communities" that believe(d) in this
interpretation?

Regards,

Andreas

On Tue, Jul 28, 2009 at 15:35, R J Scheuerle Jr<scheu@us.ibm.com> wrote:
> FYI,
>
> There were some gray areas in the StAX specification with regards to the
> semantics of "set prefix".
>
> In addition, there was an example in the specification that matched
XLXP-J's
> interpretation.
>
>
> Thanks,
>
>
> Rich Scheuerle
> Senior Programmer, IBM Web Services
> Development, Support, and Open Source
> Apache Axis2 (scheu@apache.org)
> 512-286-8420 (IBM TL 363-8420)
>
> Andreas Veithen ---07/28/2009 07:34:54 AM---Dims,
>
> Andreas Veithen <andreas.veithen@gmail.com>
>
> 07/28/2009 07:33 AM
>
> Please respond to
> commons-dev@ws.apache.org
>
> To
> commons-dev@ws.apache.org
> cc
>
> Subject
> Re: Stax parsers - one more variation
> Dims,
>
> I just stumbled over TUSCANY-1818. When reading this together with
> WSCOMMONS-66 and WSCOMMONS-262, things become clearer. Apparently,
> what happened is that in the first versions of XLXP-J, IBM didn't get
> the StAX specs right and Axiom had to adapt to this, i.e. the vague
> term "user community" actually refers to IBM! When they finally
> recognized this problem, they introduced the
> javax.xml.stream.XMLStreamWriter.isSetPrefixBeforeStartElement
> property as an elegant way to rectify this without making too much
> noise. Brilliant!
>
> Andreas
>
> On Tue, Jul 28, 2009 at 09:21, Andreas Veithen<andreas.veithen@gmail.com>
> wrote:
>> Dims,
>>
>> Actually I initially developed the idea to have the concept of a "StAX
>> dialect" in Axiom when I saw this piece of code. I started to
>> implement this feature when trying to solve the thread safety issue,
>> but the aim is clearly to get rid of the isSetPrefixBeforeStartElement
>> hack(s).
>>
>> I had a closer look at the code during the weekend, but I fail to see
>> in which case we would actually need/have
>> isSetPrefixBeforeStartElement == true. In my opinion, the StAX
>> specifications don't leave enough room for the second interpretation
>> (that setPrefix would apply to the next writeStartElement) [1]. Also,
>> of all the StAX implementations I've seen, none expects this. Do you
>> have any idea which "user community" "believes" this?
>>
>> Andreas
>>
>> [1] http://people.apache.org/~veithen/axiom/devguide/ch02.html#d0e69
>>
>> On Tue, Jul 28, 2009 at 00:45, Davanum Srinivas<davanum@gmail.com>
wrote:
>>> Andreas,
>>>
>>> Not sure if you have seen this already. There's some convoluted code
>>> in org/apache/axiom/om/impl/util/OMSerializerUtil.java (method
>>> isSetPrefixBeforeStartElement) which basically has a toggle based on
>>> the parsers.
>>>
>>>            // Fallback: Toggle based on sun or woodstox implementation.
>>>            NamespaceContext nc = writer.getNamespaceContext();
>>>            ret = (nc == null ||
>>>                    (nc.getClass().getName().indexOf("wstx") == -1 &&
>>>                            nc.getClass().getName().indexOf("weblogic")
==
>>> -1 &&
>>>                            nc.getClass().getName().indexOf("sun")
==
>>> -1));
>>>
>>> The javadoc has more information:
>>>
>>>    /**
>>>     * Unfortunately there is disagreement in the user community about
>>> the semantics of setPrefix on
>>>     * the XMLStreamWriter.  An example will explain the difference:
>>> writer.startElement("a")
>>>     * writer.setPrefix("pre", "urn://sample") writer.startElement("b")
>>>     * <p/>
>>>     * Some user communities (woodstox) believe that the setPrefix is
>>> associate with the scope for
>>>     * "a" and thus remains in scope until the end of a.  The basis
>>> for this believe is
>>>     * XMLStreamWriter javadoc (which some would argue is incomplete).
>>>     * <p/>
>>>     * Some user communities believe that the setPrefix is associated
>>> with the "b" element. These
>>>     * communities reference an example in the specification and
>>> historical usage of SAX.
>>>     * <p/>
>>>     * This method will return true if the setPrefix is associated
>>> with the next writeStartElement.
>>>     *
>>>     * @param writer
>>>     * @return true if setPrefix should be generated before startElement
>>>     */
>>>
>>> Can you please take a look?
>>>
>>> If we can find a way to totally remove the need for caching the
>>> boolean after checking the xmlstreamwriter, that would be a big bonus.
>>>
>>> thanks,
>>> dims
>>>
>>> --
>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>
>>
>
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message