Re: COMPLEXITY BIG ISSUE

[Christopher Ferris <chris.ferris@east.sun.com>]

David,

I also favor camel case versus ALLCAPS for readability. However, I think that
we should
avoid abbreviations as they aren't as easily recognised in non-english speaking
domains.
If the aim of abbreviation is to keep the document size smaller, compression or
tag substitution
is a better approach.

Yes, performance may indeed become an issue, but let's not design in
optimzations until
we know that they are required. According to Moore's Law, processor speeds will
have
doubled by the time the ebXML specifications are deployed and it is also likely
that XML
parser performance optimizations will have improved performance to the point
that resorting
to abbreviated or encoded tag names will have been a waste of time.

Cheers,

Chris
David Burdett wrote:

> 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