RE: COMPLEXITY BIG ISSUE (performance, more)

["Peter D. Pruyne" <pdp@mcs.net>]

Much snipping here to isolate David's comments

> ## 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.##
> 

While I think it is premature to dictate style in the interest of 
performance, I think this kind of digest would be a good idea in any 
event.

>   Also,
> the overuse of attributes can slow incoming parser and handling routines. 
> A shallow, self describing XML message is ideal.
>

	Once you accept the 10-20x expansion over edi, I think the 
structure of the message becomes a smaller issue.

As for attributes, since the search spaces are very small (only the 
potential attributes for the particular element are relevant), I don't 
think this is a big issue.

Interestingly, a "deeper" message also helps in the same way, by 
reducing the search space at each point in the hierarchy.   

Also, one presumes that most attributes are carrying semanticly 
important information.  That information needs to be carried 
somewhere.  The depth aspect implies semantic-relationships as 
well (at least to me), more seems better.  (Note EDI might be 
described as "very flat").  

Oddly. the search space impacts (which I think dominate) would 
seem to be favorable for both "deep" and "attribute-rich".

> 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.##

	This  I agree with as well.

>   Names should be kep short for optimizing procesor overhead and
> reducing message.length()

	In general shorter would be better, but "short" is probably in the 
eye of the beholder.

> ##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>.

	I think a "guideline" would be good in any event.  Perhaps in a 
style guide.  I would suggest a power-of-two number, say 32.  A 
"style guide" would seem to be a suggestion to pass on to the 
requirements folks.


PDP