You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2003/11/13 22:52:07 UTC
SAX done better?
Hi all,
just been reading up on the new StAX API
(http://jcp.org/en/jsr/detail?id=173)
can't help being (a bit) enthousiastic, looks to me like an important
step into the direction of efficient parsing of XML
(seems to be more valuable then just a symbiosis of the existing pull
parsing approaches currently out there)
the spec is short and provides a genuine brain-feeding read: in fact one
gets to notice how SAX left some room for efficiency improvements: e.g.
the characters event in SAX cannot be trusted not to reuse the same
buffer variable which means you have to do a mem-copy on the event even
if only later in the event-stream you can decide that you could discard
it anyway...
still have to do some personal tests to really dig what they mean with
their proclaimed pipelining support, but already I have the idea that
this is one to keep an eye on in our line of working (e.g. FO
implementations could benefit IMHO)
also their (to be done in future release :-() 'virtual data source' is
read by me as some natural fit on our pseudo-protocols meeting
java-beans passed/stored in the request, flow or session context
well, if nothing else, the trendspotter in me kind of noticed this:
# Support for non-namespace aware documents becomes optional!
==> You are running out of excuses to not be doing namespaces!
# XML's verbosity is calling upon some efficiency focus
==> XML starts being used in domains with large datasets or documents
# SAX-meme is infecting XML-designs
==> Sensible improvements (more avoided mem-copies)
==> Another API endorsing the XML-Pipeline-Processing paradigm
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: SAX done better?
Posted by Davanum Srinivas <di...@yahoo.com>.
:) currently in listen mode mostly :)
-- dims
--- Sylvain Wallez <sy...@apache.org> wrote:
> Davanum Srinivas wrote:
>
> <snip/>
>
> Hey, nice to see you here again, Dims!
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> Orixo, the opensource XML business alliance - http://www.orixo.com
>
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: SAX done better?
Posted by Sylvain Wallez <sy...@apache.org>.
Davanum Srinivas wrote:
<snip/>
Hey, nice to see you here again, Dims!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: SAX done better?
Posted by Davanum Srinivas <di...@yahoo.com>.
FYI, threads on xerces-j-dev:
http://news.gmane.org/onethread.php?group=gmane.text.xml.xerces-j.devel&root=%3C3F80F438.2060500%40apache.org%3E
http://news.gmane.org/onethread.php?group=gmane.text.xml.xerces-j.devel&root=%3COFF6864861.CC02E004-ON85256DAB.006F7AF0%40ca.ibm.com%3E
--- Marc Portier <mp...@outerthought.org> wrote:
> Hi all,
>
> just been reading up on the new StAX API
> (http://jcp.org/en/jsr/detail?id=173)
>
> can't help being (a bit) enthousiastic, looks to me like an important
> step into the direction of efficient parsing of XML
> (seems to be more valuable then just a symbiosis of the existing pull
> parsing approaches currently out there)
>
> the spec is short and provides a genuine brain-feeding read: in fact one
> gets to notice how SAX left some room for efficiency improvements: e.g.
> the characters event in SAX cannot be trusted not to reuse the same
> buffer variable which means you have to do a mem-copy on the event even
> if only later in the event-stream you can decide that you could discard
> it anyway...
>
>
> still have to do some personal tests to really dig what they mean with
> their proclaimed pipelining support, but already I have the idea that
> this is one to keep an eye on in our line of working (e.g. FO
> implementations could benefit IMHO)
>
>
> also their (to be done in future release :-() 'virtual data source' is
> read by me as some natural fit on our pseudo-protocols meeting
> java-beans passed/stored in the request, flow or session context
>
>
> well, if nothing else, the trendspotter in me kind of noticed this:
>
> # Support for non-namespace aware documents becomes optional!
> ==> You are running out of excuses to not be doing namespaces!
> # XML's verbosity is calling upon some efficiency focus
> ==> XML starts being used in domains with large datasets or documents
> # SAX-meme is infecting XML-designs
> ==> Sensible improvements (more avoided mem-copies)
> ==> Another API endorsing the XML-Pipeline-Processing paradigm
>
>
> regards,
> -marc=
> --
> Marc Portier http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://radio.weblogs.com/0116284/
> mpo@outerthought.org mpo@apache.org
>
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/