FW: Efficient XML - request for input

["Duane Nickull" <duane@xmlglobal.com>]

Here is a reply from another listserve to the message I posted asking for
comments on efficient XML.


-----Original Message-----
From: XXXXXXXXX
Sent: Tuesday, March 07, 2000 7:07 PM
To: Duane Nickull
Subject: Re: Efficient XML - request for input


You could try dropping in a "header" bit that could easily be located using
something like sgrep, and try to stick stuff in there that you need for most
processing.  It'd be a bit of a cheat, but I bet that would work.  I talked
at Comdex to one of the guys who set up Sharper Image's Web site (I think
that was it) and they did a couple of things; they jammed a bunch of stuff
into RAM, and they set up the XML so they could run sgrep against
easily-located name-value pairs in the tag structure and then dive in with
XML tools to deal with the fragments they located that way.  I did some
timing on sgrep vs. parsers and found (no surprise here) that sgrep is way,
way faster on large files.  Files and objects that are cached process really
quickly; the servlet Michael Kay sends out with Saxon caches its stylesheets
and you can really feel the difference.

If you want to go with Java, Sun just released a SAX package.  I bet
XML::Parser would be really quick, though, and I expect there is eventually
some trade-off if your structures are too complex because it has to look
ahead to figure out where the end of the element it's in is, but I've never
really tested that.  Saxon has something that lets you look ahead and
process one element at a time that is meant to improve performance, but I've
never worked with it much.

I don't suppose any of that helped, but on the off-chance that it might I
thought I'd send it.

XXXXXXXXXX


----- Original Message -----
From: Duane Nickull <duane@xmlglobal.com>
To: Perl-XML Mailing List <perl-xml@listserv.activestate.com>
Sent: Tuesday, March 07, 2000 5:27 PM
Subject: Efficient XML - request for input


> Hello all:
>
> I am involved with a large project called ebXML, a United Nation
> CeFACT/Oasis joint initiative.  One of the working Group issues that has
> recently surfaced is the issue of defining messaging semantics and
> structure.  The particular issue is how to define a message so it is
> lightweight in terms of size and overhead required for parsing and
> processing.
>
> I want to ask for help on the following issues with respect to Perl/XML
>  and other */XML combos if anyone has data):
>
> Has anyone actually got use case test data on parsing/timing different XML
> structures?
>
> Can anyone provide insight into what inefficient XML vs. efficient XML
might
> be?
>
> How is XML::Parser affected by bad use of attributes/too many elements etc
> in respect to DOM
>
> Thank you for any insights.
>
> Duane Nickull
>
>
> ---
> You are currently subscribed to perl-xml as: [halstedd@tcimet.net]
> To unsubscribe, forward this message to
>          leave-perl-xml-81535H@lyris.ActiveState.com
> For non-automated Mailing List support, send email to
>          ListHelp@ActiveState.com
>
>