archives? performance/design issues?

[Andrea Foster <Fo...@telkom.co.za>]

Hi

I've tried to get to the xml.apache.org mailing list archives. In
particular the xerces-j ones.

from the link on xml.apache.org I get this page:

http://xml-archive.webweaving.org/

Which says to go to this site:

http://archive.covalent.net 

which my browser does _not_ like. I keep on getting timeouts. Been
trying on and off now for over a week. With regards to the timeouts I
have no problems getting to http://covalent.net - which incidentally
shows 
no hits for "xml mailing list archives" with its search facility.

???

Background on current project. Its a pilot slice of a big hairy thing.
Currently its -  
(xml->servlet -> decision/dispatcher class -> classes that call backend
CORBA code). 
servlet code is (parse -> pass data to dispatcher->get simple
result->reply). 
dispatcher is (big case statement)

Conversation between A (who gets to do the coding) and Boss (who gets
to handle the flack) about parsing-
A  :  except for a couple of very simple data type value mappings we
don't need to do manipulation of xml data - all we want is to extract
the information - (we think we need minimal information for dispatcher
to decide which handler should deal with the message, but then later the
specific handler needs to populate various complex data structures to Do
Various Things with) SAX is perfectly fine for this. DOM is memory
intensive and has performance issues, and traversing its tree is a pain.

Boss says : I like that you can pass a standard DOM object around and
defer dealing with what data to extract to much later...
A replies : but I can build up a application-specific data object that
has get methods when I do the SAX parsing inside my ContentHandler and
pass that around....
Boss says : Then your parsing code needs to know business logic/message
structure. And why should the parsing code change when the xml messages
get changed?
A says : How about using  JDOM? Can use SAX parser get a document to
pass around and have more straightforward method calls hence clearer
more easily maintainable code.
Boss replies - Its still in beta. Unless for very good reason beta's do
not get into production code.

+ more stuff that resulted in current quest for more facts.

To make matters worse, we still don't have the finalised XML message
formats. But we suspect there will be 3 basic message types - mostly
"flat" , that depending on their data result in 5 times as many
different "backend instruction sets". We know what the data has to be
(since the backend stuff is existing and currently unchangeable) , but
not how its going to be bundled into the xml.

So - these design/performance issues have probably been discussed to
death but since I can't get to the archives - any input from the list at
large?
And yes, I'm looking for good reasons to not use DOM. Boss wants firm
figures and not "its advised that ..." or "it uses more memory". He
wants to know specifically by how much for specific example messages.
And/or suggestions for a better design.

ps. for brevity I didn't get into the schema issue.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org