[Home] [By Thread] [By Date] [Recent Entries]
Mike Champion wrote: > >3. XML is not easy. > > Hmmm, I'm of two minds. On one hand, the whole bloody mess > of specs is a nightmare, but I really do believe that the > bare essentials -- well-formed elements, attributes, text > with a little help from SAX, a DOM subset, and an XPath/XSLT > subset -- provides quite a bit of gain for not much pain. In my experience, the problems come on the tools side, not the application side. When I write/design tools, I spend most of my time trying to niggle out ways to handle the obscure bits: entities, order in an order-free world (I work with data), the intracacies of schemas, etc. Many of these are unimportant to most of my customers, but must be covered for completeness. On the other hand, when I write applications, XML is easy to use. My DTDs are data-centric (SML-like) and the resulting documents are easy to process. I have also found that XML is a really nice data design tool. To explain: a significant part of the input to my tools consists of documents. These are compiled into internal structures and then processed by a generic engine. What I have found is that I end up designing both documents and internal structures in parallel, and that this process provides a nice set of checks and balances. The documents must be easy to understand, and the internal structures must be easy to process. Thinking of these first from the UI point of view, then from the processing point of view leads to cleaner design than I could have done designing only one side or the other. -- Ron
|

Cart



