RE: [emergency] Circle and Polygon

["Bullard, Claude L (Len)" <len.bullard@intergraph.com>]

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:kon@datacast.biz]

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:kon@datacast.biz]
> > 
> > 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.