RE: COMPLEXITY BIG ISSUE

[David Burdett <david.burdett@commerceone.com>]

Duane

Some thoughts below marked with ##

David

-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Tuesday, March 07, 2000 11:50 AM
To: David Burdett; 'ebXML Transport'
Cc: 'ebXML Architecture'
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.
## Another way you can optimize this is by building into the Message
Manifest or wrapper of non-XML data, information about what is inside the
"BLOB". This way, you can determine how to process the data. For example in
the example you describe, a SAX approach would probably be faster than a
DOM.##

  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.
##This is my personal view too.##
  Names should be kep short for optimizing procesor overhead and
reducing message.length()
##Double edged this, my view is to have a guideline that says, say:
1. Names that are less than 20 characters (say) should use the unabbreviated
name
2. Names that are more than 20 characters **should** be abbreviated
according to an abbreviation rule, for example omitting all vowels and
repeating letters. This would mean that <MessageHeader> would be become
<MsgHdr>.

Somewhere I've got a a proposal along these lines for naming database fields
that I developed for an oil company in the 80s##

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