[
Lists Home |
Date Index |
Thread Index
]
At 1:00 AM +0000 11/9/03, Alaric B Snell wrote:
>Now, as I see it, the argument for (2) is that a
>backwards-compatible optional extension to SAX might be a bit messy
>(having characters() and value() callbacks, along with something to
>allow attributes values to be provided as native data - even when
>some other attributes might not be typable by the parser...), rather
>than any fear of it polluting XML, since we clearly *can* do it in a
>non-polluting way...
No, you can't do this in a non-polluting way, which is why it should
be a separate API. If there are features in the API, then the
documentation has to describe them. The books have to cover them. The
trainers have to teach them, even if it's only to say "This is one of
the most brain damaged things ever invented, you don't need to know
it, and you shouldn't use it." There's a real, practical cost to
adding features, even optional ones that you're ignoring.
And in practice options tend toward one of two asymptotes: either
enough people start using them that parsers are required to implement
them, or few enough parsers implement them that no one feels safe
using them. The ideal number of optional features is zero.
XML and binary formats are different things. They need different APIs
that can be learned, understood, and used independently of each
other. Binary API shouldn't compromise themselves in the name of XML
compatibility. XML APIs shouldn't compromise themselves in the name
of binary compatibility. Let each tool be designed to do one thing
and do it well, rather than doing everything poorly.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
