RE: web worries

From: Bob Neches (
Date: 10/09/00

I remember my initial peevish reaction to moving from FORTRAN to ALGOL(in
1972): why do I have to learn all this syntax to write a line of ALGOL, I
thought, when I can do the same thing in only six or ten simple FORTRAN
statements that I already know?  By the end of the course, I understood.

This article reminds me a bit of that: few people really like to learn
things without knowing there's a payoff.

A key point in this, though, is that things will more easily take off when
the tools start to hide some of the implementation complexity from users, as
opposed to forcing them to wallow in it.

-- Bob

-----Original Message-----
From: Dan Connolly []
Sent: Monday, October 09, 2000 2:06 PM
To: John Flynn
Subject: Re: web worries

John Flynn wrote:
> All,
> The site below contains one person's concern about the direction the web
> taking.

Ha! The irony!

Dvorak writes:

    " the elegant simplicity of plain HTML is being shoved
	aside in favor of the increasingly complex XML scene."

but try "view source" on that article. This is elegant simplicity?


                <SCRIPT LANGUAGE="JavaScript">

if (isIE4PC) {document.write('<DIV
if ((isNav3) || (isNav4)) {document.write('<TABLE WIDTH="610"



I find that XML simplifies life considerably. Or rather:
it doesn't complicate life more than life is already

The HTML specifications, for example, aren't worth much
to implementors (I think they are to authors, but...).
I routinely hear reports from implementors that coded
to the spec, and then tried their code on the HTML
that's actually out there, and spent between 3x and 10x
their original investment trying to be bugward compatible.

HTML is, by and large, another write-only medium, like

XHTML, when used carefully, can be the basis of
rich interchange. XML in general can too.

For example, over the last few days,
I just built some XML/XSLT tools to help me do expense reports:
I export tab-delimited stuff from Quicken,
then turn that into XML with a ~100-line python script,
then munge the data with XSLT, turning it into
RDF and doing semantically-rich queries on it. Total lines of code,
including quite a bit of comments: less than 1Kloc:

    175     443    3506 quicken-export/
    221     466    6673 quicken-export/reportSemantics.xsl
    134     294    4317 mit2000/mergeExpense.xsl
    530    1203   14496 total

The result is a nice looking expense report that cites
the relevant MIT policies and such. Before this DAML
project is all said and done, I should be able to prove,
by machine (with interactive input from the authorized
parties) that the expense report conforms to the
relevant policies.

But for now, it works. I can write XML out of one
tool and read it into lots of other tools with 100%
reliability. (Try that with HTML: write a document
with HTML tool X; read it into tool Y; modify
it a bit; write it back out; try to read it into tool X
again. Do you even recognize your document?)

This is stuff I just couldn't manage before tools like XSLT
were avaialble. I either lived with Quicken's report
formats, or I transcribed all the data, by hand, into
a spreadsheet or something.

The various ways people stretch HTML and javascript
to approach live's problems are amazing (webturbotax
completely blows me away!) but they're anything *but*
"elegant simplicity". They're hacks upon kludges,
and they rarely survive more than 18 month's worth
of software-upgrade-turnover.

XML tools, on the other hand, compose quite nicely
to build big solutions out of little ones.

Dan Connolly, W3C
tel:+1-913-491-0501 (office phone as of 27 Apr 2000)

This archive was generated by hypermail 2.1.4 : 03/26/03 EST