From: Dan Connolly ([email protected])
Date: 10/09/00
John Flynn wrote:
>
> All,
>
> The site below contains one person's concern about the direction the web is
> taking.
>
> http://www.zdnet.com/ecommerce/stories/main/0%2C10475%2C2636521%2C00.html
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
STYLE="position:relative;top:0;left:0;width:630">');}
if ((isNav3) || (isNav4)) {document.write('<TABLE WIDTH="610"
CELLPADDING="0" CELLSPACING="0" BORDER="0"><TR><TD VALIGN="TOP"
WIDTH="142">');}
</SCRIPT>
==========
I find that XML simplifies life considerably. Or rather:
it doesn't complicate life more than life is already
complicated.
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
postscript.
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/tsv2xml.py
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 http://www.w3.org/People/Connolly/
tel:+1-913-491-0501 (office phone as of 27 Apr 2000)
mailto:[email protected]?subject=pls%20call%20+1-NNN-NNN-NNNN
This archive was generated by hypermail 2.1.4 : 03/26/03 EST