Maybe, but it is something that most proficient
XML programmers are aware of. Verbosity matters.
I'd be pretty unhappy to find someone implementing
a messaging switch of any kind with the DOM. It
has it's uses but they are mostly in the client.
That said, some of my guys did exactly that so
it isn't uncommon.
What is useful is a SWAG at average sizes, but that
has to be noted in an informative section. I'd
sure like to see some realistic performance requirements
for EMT systems. Overlapping requirements for
communication AND data mining may be pushing us
toward a pie in the sky design that falls down
when we throw the switch.
<rant>Apologies in advance.
But this comes around the central issue of why
we want to share schemas as much as possible.
Even in the SAX approach, one has to recognize
the incoming names and dispatch on them, so the
big namespaces with lots of variants add code
bloat. If we optimized CAP for using all of its
own tag names and that has to exist side by side with
a duplicate set for precisely the same information,
that is redundant code regardless of the approach
taken. This is what I am getting at with the
liaisons and all of the overlapping but separately
managed specs. If this churns a lot, we burn
a lot of programmer effort, certification effort,
time on the phone, and so on trying to keep a
system running just to manage the different
control loci and their requirements. That isn't
cheap. This is what I mean by 'hot zones'. The
system is abstractly thermodynamically wasteful.
My hope is that DHS and DoJ settle down
on a few providers for the designs and then hold
their feet to the fire about consistent non-overlapping
vocabularies. Someone soon will have to take a very
hard mean look at GJXDM, CAP, EDXL etc., and prune
them. It's a rotten job but the closer we get to
real time applications, the more necessary. One
may also want to revisit the ISO naming conventions
and ask if maintaining that much context in each
document tree is really helpful or just theoretically
elegant.
When gardening, one doesn't 'let a thousand flowers bloom'.
One prunes relentlessly and daily.
</rant>
len
From: Kon Wilms [mailto:]
On second thoughts, perhaps this issue with large files is something
that needs some sort of addressing.
Taking CAP as an example - the examples in the spec doc are fairly
short. Someone may lean towards testing these with a DOM parser + schema
in order to build an application, and 'ship it' because it appears to
work fine. Trouble comes later due to the (as Carl points out) fact that
we don't know what amount of data will be in the files we receive.
This is something I believe should be pointed out in the spec documents.
Cheers
Kon
On Fri, 2005-06-10 at 09:55 -0700, Kon Wilms wrote:
> Nod. It had to be mentioned, was all.
>
> Cheers
> Kon
>
> On Fri, 2005-06-10 at 11:36 -0500, Bullard, Claude L (Len) wrote:
> > The DOM parser may be the wrong implementation approach.
> > A SAX-like parser (eg, XMLReader) is a way one handles
> > large documents. It is harder to implement but much
> > faster. The problem one wants to avoid is premature
> > optimization of the wrong piece of the technology.
> >
> > len
> >
> >
> > From: Kon Wilms [mailto:]
> >
> > That issue is not uncommon. Its standard practice for most DOM parsers
> > to load the entire XML file into memory before parsing. Get a few of
> > those going with threads and RAM decreases fast. I am sure that everyone
> > using fast desktop workstations with a gig of ram don't even notice it.
> > The little guys with 64MB of RAM on an embedded system do, however.
> >
> > This would be about the time where I wave my 'split the resources into
> > separately referenced files' flag.
> >
> > Ofcourse, this could also be purely a speed issue with some code that
> > needs optimization.
