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<[email protected]> 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 ([email protected]) > 512-286-8420 (IBM TL 363-8420) > > Andreas Veithen ---07/28/2009 07:34:54 AM---Dims, > > Andreas Veithen <[email protected]> > > 07/28/2009 07:33 AM > > Please respond to > [email protected] > > To > [email protected] > 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<[email protected]> > 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<[email protected]> 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 >>> >> > >
