[
Lists Home |
Date Index |
Thread Index
]
> As long as that core remains untouched, all of the debates
> on loose and tight coupling, schemas, strong typing vs
> lexical and structural named types, are simply and
> only choices of the application engineer.
I have to admit that I'm incredibly sick of the "don't worry about how
huge and crappy the specs are - the application engineer just gets to
pick and choose the parts they want to use."
I thought we'd gotten past this hurdle when XML discarded all the
optional bits of SGML, rejecting the build-your-own-markup-structures
options in favor of creating systems that could be widely shared and
interoperable without profound and tedious negotiation.
XML 1.0 by itself seems to have been designed to avoid the need for such
negotiation, reducing the level of coupling needed to build useful
applications substantially at the outset. As we move "forward", that
lesson appears to be getting utterly lost under a huge pile of features,
and now we have to negotiate all that crap yet again just to share
files.
Coming up with vocabularies is difficult enough without having to choose
from the feature set of "Greater XML". Expecting that these extra
features won't make that process even more difficult over time seems
blissfully naive.
If every application engineer was an island, I'd give this theory a tiny
bit of credibility. As very few XML application engineers have that
luxury, I think it's time to stop pretending that Greater XML can be
ordered a la carte.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
