[
Lists Home |
Date Index |
Thread Index
]
Seems to me that the bottle neck is not IO, or network, for those people
should be talking about compression. The bottleneck seems to be parsing the
XML back into a set of useable objects. Apart from reasonably standard
forms such as SAX processing and DOM representations, there are various
other forms of storing deserialized XML. Many of these use SAX underneath,
so if this is your bottleneck, then persist a binary form of the events
given - say as a vector of event objects, and reuse this. Perhaps
persisting a binary form of a DOM tree is what you want.
In the end, I don't think the argument is about a binary form of XML, it is
about standard binary forms of deserialized XML. The problem with that is
that you aren't talking about XML anymore :-)
----- Original Message -----
From: "Robin Berjon" <robin.berjon@expway.fr>
To: "Mike Champion" <mc@xegesis.org>
Cc: <xml-dev@lists.xml.org>
Sent: Thursday, February 27, 2003 7:12 AM
Subject: Re: [xml-dev] Use cases for parsing efficiency (was Re: [xml-dev]
Parsing efficiency? - why not 'compile'????)
> Mike Champion wrote:
> > As a matter of fact, until a few
> > months ago I was as much a scoffer at the arguments that Al and Robin
> > raise as any of you.
>
> As was I until I stopped thinking that people that used XML in the
situations
> where binary infosets are needed were doing something stupid or evil and
started
> looking at some real life use cases. If in a system XML works great
overall and
> fails on one or two points, it's better to address those points than to
throw
> out the baby with the angle brackets.
>
> > My day job colleagues changed my mind by pointing out that in
> > industrial- strength, native XML processing environments, nothing much
> > is happening besides XML being parsed, processed (stored, queried,
> > transformed) and serialized again. (...) I've heard the same
> > thing from industrial-strength SOAP developers -- as the volume of
> > messages goes up and processing resources get dedicated to XML (i.e., no
> > application logic or DB access happening on the machine parsing,
> > processing, serializing the XML), then the bottlenecks in XML parsing
> > become increasingly apparent.
>
> If you have any more or less detailed stories/numbers/examples I'd be
happy to
> have them (offlist) to see if they bring up points we haven't covered yet
and
> coroborate our feedback and experience with binary SOAP.
>
> > So why should you all care about standardization of processing pipelines
> > that are generally *internal* to products?
>
> Because they're not necessarily internal :) What happens if you want to
plug two
> high-performance SOAP implementations together that both use different
binary
> infosets? What do standard bodies that include SOAP in their specs and
want to
> use binfosets because they are targetting a variety of platforms, some of
them
> constrained use as their format? An audio-video MPEG-7 stream contains
literally
> tons of metadata (originally XML) how does my SemWeb agent use that to
order
> pizza when the finale starts so that I have it right when the film is
over?
>
> Binfosets are considered for MMS. That's not very internal :) etc.,etc.
>
> > I'm not completely sure you
> > should. One might argue that you as customers of / developers for
> > enterprise-class XML processing software may wish to tap into the
> > pipelines at a lower level, e.g. grab the rawest Infoset data out of a
> > DBMS before it gets sanitized and standardized by the API level
>
> If what you want is really high speed processing then it's likely you'll
want to
> do that. We have a low-level API (SAXt) and high-level APIs for
transparency
> (typically SAX), and the speed difference is very much noticeable.
>
> --
> Robin Berjon <robin.berjon@expway.fr>
> Research Engineer, Expway http://expway.fr/
> 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
