[
Lists Home |
Date Index |
Thread Index
]
The problem is, they aren't interoperable. They
are just portable. And without strong typing,
a database isn't terribly efficient. One might
want to stop and ask about XML databases and does
one really need them. If one stops with "XML
will be applied as a serialization", one can
get away with that.
Sick though ye may be, that's markup. You can't
have it both ways. The specs are not XML except
for XML 1.0. That's core. The specs can be as
huge and crappy as people want to make them. XML
Doesn't Care, so a defense or an attack based on
them that says "that ain't XML" is both correct
and irrelevant. SGML didn't allow one to
build their own markup structures in the sense
that just like XML 1.0, ISO 8879 was the whole
of the law for SGML itself. Yes, it had more
options, true, but also irrelevant. That was
fixed when XML 1.0 was released. This isn't
ISO 8879 being discussed here and yet another
"we'll blame SGML" argument is just noise. This
is the XML subset of SGML being discussed.
Now, where are your problems starting? Not in
XML, but in these "crappy" specs as you say.
1. If you don't need XQuery, XSD, etc., don't
use them.
2. If those who need them build them, you have
no complaint. That's their choice.
3. If those you need to work with require them
you can
a) Explain what the problems are to those people in
terms of those requirements
b) Not work with those who need them
c) Offer alternatives to meet those requirements.
One can't stop the W3C or any other organization
or individual from exercising their right to build
applications and systems using XML. One can rightfully
resist their claims that these applications and systems
are essential parts of XML. They aren't any more than
a MS Word is a rightful part of C++.
It comes down to choices, quality of choices, and
who chooses. Right now, the WWW architecture is
decided by the TAG and the voting members of the
W3C. The Internet is a bigger domain. The W3C
could resist SML but could not stop it. The
SML group could create SML but also had the
responsibility to sell it. They could not
claim it was XML. Again, one can't have it
both ways. That's simple enough.
My worry is when some bozo in charge decides that:
1. Only W3C specifications will be acceptable
without reference to merit or application.
2. Members here and elsewhere applaud a decision
like that. That's technical groupyism.
3. We have to support it because it shows up
in an RFP and therefore, closes the circle of
"crappy" specs normatively referencing "crappy"
specs.
At that point, we all end up with redder noses
and overinflated shoes.
I don't mind being wrong; I can learn. I mind
being right and irrelevant.
len
-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> 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.
|
