[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> 10/30/2002 12:44:27 PM, Robin Berjon <robin.berjon@expway.fr> wrote:
>>I'm having trouble finding a SOAP toolkit that seems to be aware of this
>>paragraph however,
>
> Which is why I used the AFAIK qualifier!
Pointers welcome if you see any, I'm currently reduced to patching Axis
just to get at the wire XML, a task less pleasant than I'd like it to be.
>>In some cases it does turn out to be the bottleneck, but it's true that
>>jumping to conclusions there is a bad idea.
>
> Does anyone want to elaborate on cases when XML parsing does turn out
> to be the bottleneck? The only ones I'm aware are in pure middleware
> scenarios -- XML serialized out of one internal representation only
> to be reparsed into another internal representation almost immediately.
> Profiling/tweaking does indicate that more efficient exchange formats
> than XML (eg a sort of serialized SAX events) can significantly
> speed things up.
The cases that I'm aware of concern mostly lightweight terminals or
highly data intensive XML streams. For the former a good example is
sending SVG to a cell phone, the parsing speed (not to mention the size)
makes a huge difference. For the latter, things like MPEG-7 audio-video
metadata, or broadcast to numeric TVs and radios are typical use cases.
In addition to the middleware cases you mention, there are other
situations but they are usually less obvious. Note that Web Services
would seem to correspond to the middleware situation you describe.
> Of course, once one gets out into the open the lack
> of standardized alternatives to XML syntax for serializing the Infoset
> does tend to outweigh the performance advantages.
For the Infoset there is little that I know of, for the PSVI there is
ISO MPEG-7's BiM and its BinXML outgrowth which is what I work on.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
