John F. Sowa wrote: (01)
> XSLT is another disaster. (02)
One man's meat is another man's poison. As Kingsley said of XML, it is
a valuable tool if it is used appropriately. Or, as Doug Schenck (one
of the original authors of the ISO data modeling language EXPRESS) once
put it, "a Pepsi bottle can be used as a hammer, but that doesn't make
it a recommended practice." (03)
> There have been good tools for processing
> languages since the 1960s. I developed some myself. (04)
There are many transformation rules languages out there, yes. Some of
them are well-documented and have reliable implementations. Some of
them are easy for amateurs to do simple transformations with. Some are
powerful enough for experts to do some complex transformations
efficiently. What sets XSLT apart is that it satisfies all of those
constraints, and applies to a common form of encoding. (05)
> But XSLT is a horribly inefficient example. (06)
As compared to what? And for what purpose? (07)
> I'll admit that XSLT was designed
> for processing languages whose syntax uses XML. But for most of those
> languages, XML notation was a very bad choice -- for both human *and*
> computer efficiency. You cannot improve a bad syntax by using a bad
> tool to process it.
> (08)
To take these out of order: Most data exchange standards that preceded
XML were "bad" in two ways:
1) They involved binary encodings or weird control characters that
made it impossible for humans to examine the actual data file without a
specialized tool. (And if you suspected a bug in the tool, that left
you in a hard place.)
2) They were completely inscrutable sequences of characters that could
only be processed using a definitive schema and a knowledge of the
related encoding rules.
The idea of XML was to discard efficiency for simplicity and clarity
-- clearly delimited character data with readable labels. Having spent
many years with exchange standards of types (1) and (2), and observing
that every information exchange standard invented its own, I can tell
you that XML eliminated an enormous amount of bad interface design and
expensive software that did nothing more than provide the
encode/decode. It was an enormous step forward in getting information
exchange to be about the data content rather than the encoding. (By
complicating it, XML Schema was a giant step backwards.) (09)
As a consequence, many groups who knew (as they thought) what
information they needed to exchange were able to develop "standard"
exchange schemas that they could all easily process. This led to the
cottage industry of developing data exchange specifications -- literally
hundreds of XML-based exchange "standards" are developed by hundreds of
would-be standards organizations and other consortia every year. (010)
Enter XSLT -- the means of translation between simple XML encodings that
requires little more understanding than that required to design the
simple encodings. XSLT enables our "XML expert" to transform the
encoding of product information from the National Undergarment
Manufacturers Association to the equally simple-minded but entirely
different XML encoding of similar product information by the European
Apparel Designers Consortium. It takes only a little expertise to write
the XSLT scripts to turn these and seven others into our favorite
"standard", and then we develop only one set of catalog info processing
software. Efficiency and cost-effectiveness is defined by that last
fact. And the use of XSLT occurs hundreds of thousands of times a day
all over the planet for exactly that reason. Never underestimate the
value of simple tools for simple tasks. (011)
Yes, XSLT is a lousy language for turning RDF/XML into CLIF and changing
the spelling of most of the predicates. So what? The 216 people in
the world who want to do that were not the target user community. (012)
-Ed (013)
P.S. Yes, Jamie Clark is an erstwhile colleague. (014)
> John
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>
> (015)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (016)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (017)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (018)
|