RE: efficient XML

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello,

(sorry for mailing two lists, but it is important for both i think)

<duane>
> //dwelling
> //dwelling/house
> //dwelling/house/My
> //dwelling/house/Your
> 
> //dwelling
> //dwelling/MyHouse
> //dwelling/YourHouse
</duane>

Well.. combining multiple sub elements under a common parent has a few
advantages too.

First of all you could write a sub routine which selects on
match="house" and load it into each mapping you ever create which will
have to handle a youse. in XSL you have to do less lookups, since inside
the "house" template you have a cursor postion into the tree to access
"my" and "yours".

Second it is faster to position inside a tree if you have to skip/search
over a parent node instead of dozent parent childs. So actually movin in
a DOM document is faster if it is "deeper". With the SAX parser there is
not much performance loose if you have a "deeper" document, since it
simply generates a few ignored events.

But I guess thats outside of the Architecture's Scope Anyway.. the only
real Problem we have is that a DOM Parser will need to read the root tag
(therefore the whole message) to access the transport header.. therefore
the question is, if you want to attach the header in the same XML
document or as a attachement in the transport protocol... it's an old
problem, in EDI with leading headers (one line) you have to copy the
complete EDI file and skip the first line to reconstruct the document
without a header... that wont be needed if you never attach them on a
document level. Personally I am not sure which is better.. detached
routing, signatures, history, attachements or inlined. Inlined will
require less support from the tranporter, detached will require less
work on the documents, once transported to the endpoint. Perhaps both
options together (with a header which will include the transferred data
eighter as a link or inlined). This will work with XLinks inside
multipart MIME!

Greetings
Bernd