Re: XML Performance Community Group

The question is more how we can build a higher performance stack from the
parsing (pull parser), validation and transformation but without having to
go down to assembler

For example, doing streaming in XSLT and XProc is one potential answer to
allow higher level manipulation of data

But even with XSLT and XProc, we're still probably too lower level to allow
average user to think of XML other than just something we do binding (JAXB)
for passing as object to process it further later

Same apply for use cases where people do STORE first and then process. There
is certainly room for uses cases (for example projection) where we can apply
simple processing on the fly without having to store all the data first in
database

So the point here is more to improve *percieved* performance and *percieved*
performance/complexity ratio than inventing what's already exists

It's also probably the time to build some stack of tools that cooperate well
on XML Processing and try to permits various area that works with XML to be
able to sync on the topic of Performance (for example XML Security)

Hope this helps understanding the guideline of the Community Group

Mohamed




On Fri, Aug 26, 2011 at 7:19 PM, Santiago Pericas-Geertsen <
Santiago.PericasGeertsen@oracle.com> wrote:

>
> On Aug 26, 2011, at 1:10 PM, Tatu Saloranta wrote:
>
> > On Fri, Aug 26, 2011 at 5:18 AM, Innovimax SARL <innovimax@gmail.com>
> wrote:
> >> Thanks Robin for spotting this to all the EXI-Fan
> >> You're very welcome to the group. EXI is indeed a very important part of
> the
> >> efficient XML processing stack
> >> The point here is to help user to think into processing data *directly*
> in
> >> XML, instead of mapping/storing/building tree first
> >> Let's continue this discussion on the xmlperf mailing list
> >
> > Isn't this (avoiding of building a tree) what most high-performance
> > XML tools do anyway.... dom tree is perhaps the biggest performance
> > drain on overall processing, if one is built. So what's new here?
>
>  My thoughts exactly. How is this different from processing XML using the
> existing push/pull models?
>
> -- Santiago
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €