ws-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Stax parsers - one more variation
Date Tue, 28 Jul 2009 13:04:08 GMT
Andreas,

I have no clue what happens in the StaX JSR mailing lists...All i know is that there are variations
between the stax 
impl(s) currently in the field and this is the only check where we could not find a better
way to manage the variations 
cleanly. Which is why the dialect stuff introduction is a good thing :)

thanks,
-- dims

On 07/28/2009 08:33 AM, Andreas Veithen wrote:
> 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
View raw message