Use cases for XML failure (was Re: #2 Re: [SML] Whether to support Attribute or not?)

[Gavin Thomas Nicol]

> 2- XML is bloated with kludgy stuff that serves no real
> purpose except for traditional SGML-like text processing applications,
making
> it unnecessarily hard to learn and implement, and ultimately fragile to
build
> upon.  I must say that I'm becoming more enamored of this argument as we
go along.
>
> The relevance of my DOM ranting was to point 2 -- XML-related
> specs and tools are unnecessarily complicated and delayed by the need
> to support the least generally useful bits of the core spec

In as far as that goes, I'll agree: some parts of XML are unnecessarily
complicated for certain applications... and I'll admit to arguing strongly
for some of these things (in fact, both CDATA and entities). Still,
this "unecessary complication" is only so for certain application domains,
and I don't see them as leading to the necessity for something like
SML.

Rick's post may have been interpreted as somewhat specious... but he is
correct: without any good use cases that *prove* the necessity for SML,
and that set the requirements for it, SML is just an effort in removing
features from XML... the ultimate result of which is likely to not be
too far removed from s-expressions with angle brackets.

Personally, I'd love to hear from some of the phone companies. I'm sure they
would never claim that in a year, new mobile devices will still be so
limited that XML support is out of the question. If they *could* make
such a case, I'd be more than willing to think about things again.

FWIW. Mike, I hope you know that at heart I'm as much of a minimalist
as you are.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)