OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: COMPLEXITY BIG ISSUE


<DAVIDB>
I think therefore that the software library approach is the more likely.
However this doesn't mean that we can therefore make the spec arbitrarily
complex. We must still aim for simplicity for all the reasons you state.
</DAVIDB>

I totally agree with the simplicity.

One thing I haven't seen discussed is the actual XML processing overhead.
We have worked on parsing XML for two years and the experiences have taught
us that forming "efficient" XML is probably one of the most important
considerations for optimizing systems.

An XML message with <tag><tag><tag> "250kb garbage" </tag></tag></tag>  will
take heaps o' memory and time to load into the DOM and not give you much of
an advantage over text, yet many people write their XML this way.  Also,
the overuse of attributes can slow incoming parser and handling routines.  A
shallow, self describing XML message is ideal.

I also believe that mixed camel case will be the best syntax for element
naming conventions.  IT is more intuitively readable than all lower or all
CAPS.  Names should be kep short for optimizing procesor overhead and
reducing message.length()

The GoXML XML Search Engine currently has around 125,000 XML documents
indexed so we see many examples on a daily basis.

I will share the experiences of our company to the message architecture
group (if needed).  Rik, David et al are very knowledgable and have probably
already thought this through.

Duane Nickull
XML GLobal




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC