[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]
Powered by eList eXpress LLC