Lists Home |
Date Index |
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.