Return-Path: Delivered-To: apmail-ws-commons-dev-archive@minotaur.apache.org Received: (qmail 29845 invoked from network); 28 Jul 2009 12:32:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 28 Jul 2009 12:32:41 -0000 Received: (qmail 63313 invoked by uid 500); 28 Jul 2009 12:33:58 -0000 Delivered-To: apmail-ws-commons-dev-archive@ws.apache.org Received: (qmail 63242 invoked by uid 500); 28 Jul 2009 12:33:58 -0000 Mailing-List: contact commons-dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: commons-dev@ws.apache.org Delivered-To: mailing list commons-dev@ws.apache.org Received: (qmail 63232 invoked by uid 99); 28 Jul 2009 12:33:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jul 2009 12:33:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of andreas.veithen@gmail.com designates 209.85.218.209 as permitted sender) Received: from [209.85.218.209] (HELO mail-bw0-f209.google.com) (209.85.218.209) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jul 2009 12:33:48 +0000 Received: by bwz5 with SMTP id 5so5835908bwz.16 for ; Tue, 28 Jul 2009 05:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4uzTA0q1GfpUE7T6YjjRKaIseLR0XStgMumWftxcD8M=; b=ck1GDXI2Moe4ADoUg/UK0c92ieG9vA+9SOtyRhYtrxBcq2us9oWZfk3aeq1856nNZo TUUIM7k9Kw0iuOg45VPZkEYXWzBAInVioXNLf6eELzw4EahMz2fP3IotqsmF8/J2e4Re /8TmxgwaLWcDA5h0AVmoxbH/vRORIAavyN5to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dMavPNe/L+8tUOKKgrSfMnI7Xmeqel+KbfHddihdsKViRunzr7gwT5c86gyQ3BCfSr cpy8Lyy47UGSILMzj3WKrAvhpa3/6/GbYwa2ez2PtQZpIbDHfPjlb8c1RyZYiZ+ZFwfm WVz6jaewwg+mvRJb434r3IJEkrdXn3/EAfqUA= MIME-Version: 1.0 Received: by 10.239.163.69 with SMTP id o5mr842870hbd.40.1248784406998; Tue, 28 Jul 2009 05:33:26 -0700 (PDT) In-Reply-To: References: <19e0530f0907271545l4f455069j9767a8e7ccbeed62@mail.gmail.com> Date: Tue, 28 Jul 2009 14:33:26 +0200 Message-ID: Subject: Re: Stax parsers - one more variation From: Andreas Veithen To: commons-dev@ws.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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 w= rote: > 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 =3D=3D 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 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. >> >> =A0 =A0 =A0 =A0 =A0 =A0// Fallback: Toggle based on sun or woodstox impl= ementation. >> =A0 =A0 =A0 =A0 =A0 =A0NamespaceContext nc =3D writer.getNamespaceContex= t(); >> =A0 =A0 =A0 =A0 =A0 =A0ret =3D (nc =3D=3D null || >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nc.getClass().getName().indexOf(= "wstx") =3D=3D -1 && >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nc.getClass().get= Name().indexOf("weblogic") =3D=3D -1 && >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nc.getClass().get= Name().indexOf("sun") =3D=3D -1)); >> >> The javadoc has more information: >> >> =A0 =A0/** >> =A0 =A0 * Unfortunately there is disagreement in the user community abou= t >> the semantics of setPrefix on >> =A0 =A0 * the XMLStreamWriter. =A0An example will explain the difference= : >> writer.startElement("a") >> =A0 =A0 * writer.setPrefix("pre", "urn://sample") writer.startElement("b= ") >> =A0 =A0 *

>> =A0 =A0 * Some user communities (woodstox) believe that the setPrefix is >> associate with the scope for >> =A0 =A0 * "a" and thus remains in scope until the end of a. =A0The basis >> for this believe is >> =A0 =A0 * XMLStreamWriter javadoc (which some would argue is incomplete)= . >> =A0 =A0 *

>> =A0 =A0 * Some user communities believe that the setPrefix is associated >> with the "b" element. These >> =A0 =A0 * communities reference an example in the specification and >> historical usage of SAX. >> =A0 =A0 *

>> =A0 =A0 * This method will return true if the setPrefix is associated >> with the next writeStartElement. >> =A0 =A0 * >> =A0 =A0 * @param writer >> =A0 =A0 * @return true if setPrefix should be generated before startElem= ent >> =A0 =A0 */ >> >> 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 >> >