(Back to Rant Central)
It starts getting really good about midway through; search for
"Oh god" if you want to jump right there. Jeff's post
immediately follows Craig's.
<![CDATA[
From: Craig Brozefsky <craig@red-bean.com>
Subject: Re: XML is not so bad
To: "Bryan O'Sullivan" <bos@serpentine.com>
Cc: Jim Blandy <jimb@savonarola.red-bean.com>, cooks@red-bean.com
Date: 08 Jun 2000 16:06:42 -0700
"Bryan O'Sullivan" <bos@serpentine.com> writes:
> j> I've been reading the XML spec
> j> (http://www.w3.org/TR/1998/REC-xml-19980210), and I don't think
> j> it's so awful.
>
> That's my opinion, too. It's quite okay, in fact, being pretty much
> SGML with the egregiously silly bits removed. Who could really object
> to what boils down to trees with tags hanging off, even if they are a
> bit prolix? After all, bzip2ing an XML file gets you an agreeably
> squished-down representation.
I have done a decent bit of work with XML over the last year or so,
including writing a DTD for project management and some some DSL
stylesheets fro producing HTML reports of various types from the XML,
via Jim Clark's Jade. When I first came across it, I thought it was a
good thing too. I had several years of working with SGML before that,
again making DTDs (from scratch and with Norm's kick-arse modular
docbook DTD) and DSL stylesheets and hacking on sdc (a bigloo scheme
based SGML processor) and building all kinds of tools for SGML
processing ranging from grove producing parser interfaces to tools for
simplifying the translation of Debian documents. That said, I don't
consider myself an SGML expert, just an experienced user of tagged
markup languages.
That experience has left me with a not-so-rosy take on SGML/XML and
the standards built up around them. I feel they are basically
solutions to easy problems that create even harder problems, putting
off the solving of the harder problem onto other people and not
providing them with footholds to accomplish the task. I promise to
uphold this sense of propriety and level-minded technical evaluation
only for a few more paragraphs before bursting into a screed.
First, XML jettisoned DSL, which was at least a reasonably useful
stylesheet languages and replaced it with XSL, which itself is written
in XML and damn near impossible to look at. In general I found XML
based lanuages and description friggin' hard to read, and I have spent
many hours reading raw SGML. So now our stylesheet language for XML,
which is supposed to be the backbone of Mozilla and the "new web"s
display engine is this unreadable attempt at stuffing a programming
language into a DAG with overly verbose tags, and none of the power of
a really useful programming language (like DSL had with it's scheme
base).
Second, the forcing of everything into DAGs just makes me wanna puke.
It's an aesthetic issue that I can't even pretend to defend.
Lastly, the hard problem of denoting semantics is being brushed off as
solved by a bunch of whackos who get excited because they don't have
to write a parser. DTDs are insufficient in their definition of
document types to allow easy extension and sublcassing, and other
basic functions one excpects to be able to do with data types. There
are indeed kluges and various mechanisms people are tying to put in
place to allow this, but they are vomitous, the kind of thing that
gives you headache after 2 minutes of reading the spec. It's like a
patchwork of hacks heaped on top of one another by people who become
obsessed with one textual representation of data because they think it
will allow them to encode knowledge.
And looking at namespaces for XML, a spec which has been "in final
discussion" forever, we'll find even more hairbrained standards
wanking from the likes of MS, Sun, and Netscapes engineering staff.
XML is slowly but surely rebuilding all of the complexities and
ambiguities of SGML back in, after dumping out all of the interesting
expressive capacities.
> As far as I know, most decent languages, and their poor cousins, have
> solid and mature XML support already. Python, Perl, and Tcl certainly
> do, and they must make up about 95% of all the free-software scripting
> that happens.
There should be a guile wrapper around expat by now, I wrote a simple
ESIS parser awhile back too. There are at least three XML parsers for
Lisp that I know of, none of them "fully" compliant or anywhere near
mature tho. I suppose Lisp people are not going to fall all over
themselves and drool over something they have had for 40 odd years,
the ability to write and read data, and programs, with ease.
Oh god, that reminds me of the XSL montrosity! Make it go away, make
it go away! XSL used to generate itself! XSL processing XML to
produce XHTML, it's XML all the way down like those goddamn turtles!
Our entire world will be turned into DAGs with overly verbose tags
that only simplify implementation of parsers if you got a D- in QBASIC
in 5th grade!
The pear-shaped mouth-breathers of low-level corporate software
development teams everywhere gasping with misplaced erotic passion
brought on by their seeming omnipotence in iterating over trees
without having to understand recursive-descent parsers or any of that
other academic crap they thankfully avoided by going to ITTechnical
Institute after seeing ads for their accredited degree in systems
administration in between Hogan's Hero's and McHale's Navy.
There is no escape, can't you feel the cold hand of cycle-elimitation,
and blusterffication stroking the back of your neck, ready to snag you
by a lock of your hair and shove you head first into the XML sausage
grinder, to come out the other side as an XML document that will be
fondled and groped lavisciously yet clumsily by DOM Visitors,
Iterators and other foul demon offspring from the ring of hell
reserved for lame OO language implementors who are so embalmed in the
throwaway bourgeois epistomologic theories of continental philosphy
that they insist methods belong to objects, and that everything can be
broken into class hiearchies if we just apply a strong enough dose of
machismo-driven dialectical analysis and your inability to abide by
their categorical imperative means they must build protective and
private measures into their degenerate pidgens and creoles.
All that said, I won't hold it against you Jim if you use it.
--
Craig Brozefsky <craig@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
=========================================================================
And if you liked that, you might enjoy Jeff Dalton's critique as well:
=========================================================================
From: Jeff Dalton <jeff@todday.aiai.ed.ac.uk>
Newsgroups: comp.lang.lisp
Subject: The endless nightmare of elaboration (Re: Rob Pike article)
Date: 13 Jun 2000 14:32:22 +0100
Tim Bradshaw <tfb@cley.com> writes:
> I don't even know if this is relevent to cll, but I thought it was
> kind of interesting, although it's probably wrong of course. I liked
> the stuff about the mass of standards being crippling.
>
> http://www.cs.bell-labs.com/cm/cs/who/rob/utah2000.ps
A very interesting paper.
He's right about standards, at least in some jobs, but the nightmare
is even worse than that: every little thing you want to do is being
endlessly elaborated, because it's what's someone's research
programme or career is about.
For example, I want to send a message from one running program to
another. Nothing fancy needed; it can just be text. Simple, no?
Use a socket/pipe, define a simple syntax, ... All very easy in
Lisp because you can use READ and PRINT.
Not any more. You have to use XML. Humm. That doesn't sound too
bad. But wait, you can't just use XML. You'll have to write a DTD.
And then there are various things that are being seen as ways to
define XML "semantics" (basically: what it means as a data structure).
So you'll have to learn about them too. But you'll need to be a
bit more serious about semantics than that: you need ontologies.
"Ontologies, you say?. Well, once upon a time one might have said
something was an "int". The next step is to worry about units. Ok,
so it's an integer number of seconds. But wait a minute, what is this
"seconds"? It sounds suspiciously like a time. There's a whole world
of semantics in that word "time". You'll at least need an ontology
that covers time, and if you're not careful you'll find yourself
reading up on temporal logic. It could be worse. There are people
out there doing metaphysics and calling it "ontologies". Metaphysics
as in "just what are the fundamental constituents of the world and how
do they fit together?" Metaphysics as in thousands of years of
philosophy and still no answers. This is all just so you can send, oh
I don't know, a "3" from one program to another.
And what's this "send from one program to another?". No, no, these
days we have agents. And things that manage agents. "Brokers", for
instance, that find an agent with certain "capabilities" for you.
Capabilities? Need a language for that, and more semantics.
Don't forget the ontology.
You can forget about just "sending" too. No, no. What if the agent
on the other end doesn't want to talk to you right now, or isn't
allowed to, or wants to negotiate about the price? You can bet there
are people interested in those very issues, and not just "interested":
they plan to write and publish papers, develop software to support such
"transactions", have students doing PhDs on it, and so on.
There are - seriously - I am not kidding - people out there who will
tell you that the particular message exchange you want to do "does not
have agent semantics" and that you therefore ought to do things in
some other way that you can already tell you won't understand until
you've read several anthologies of papers.
Thank God we can still just do procedure calls. Ah, but for how much
longer? Procedures are very like agents, but they don't quite have
agent semantics ...
[I guess I'd better point out that much of this research into agents,
ontologies, etc, is both interesting and useful. But there is a real
danger that formerly simple tasks will elaborated to such an extent
that they become major projects, involving an up-to-date knowledge of
several rapidly moving fields. And I haven't even mentioned Java
Beans and a whole bunch of other stuff that will start to get in there
too.]
]]></plaintext></p></body></div>