[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: almost four years ago....
- From: Rick Jelliffe <ricko@allette.com.au>
- To: xml-dev <xml-dev@lists.xml.org>
- Date: Sun, 17 Jun 2001 16:16:01 +0800
From: "Michael Champion" <mike.champion@softwareag-usa.com>
> Not really wishing to start up the binary XML/ASN.1 argument again,
I think XML's "terseness is of minimal importance" goal should be understood
_not_ as a statement of a universal truth, but rather as a heuristic for
simplifying SGML, which, being designed for humans to use, provides lots of
ways for reducing keystrokes. (SGML says, in effect, "we can create a
highly productive interface for entering data even in a dumb text editor":
so instead of a fancy GUI where you press TAB to go to the next field in a
record so you don't need to type to explicitly close the current end-tag and
explicitly start a new one, SGML allows you to type "tab" and have the
receiving end fill in those gaps. This is one reason why swanky GUIs do not
necessary improve some kinds of data entry compared to full-featured SGML,
while they certainly may for XML.)
So "terseness is of minimal importance" says "data entry and compression
should be separate layers from data serialization notations and not tightly
coupled".
That is a refactoring of functionality: it recognizes (and creates) a
distinction between efficient data capture as a UI issue and efficient data
compression as a networking issue. If ASN.1 provides good compression, and
it can support all XML's functionality, then it clearly is a credible
candidate to restore "terseness" to XML data transmission.
Sometimes this terseness of data transmission is important (high-volume
systems) and often it is not. There is no reason to claim verbosity always
is important, and less reason to claim versbosity is never important.
It also shows why SGML is sticking around: where simple keystroke count is
a prime cost of data (e.g. data capture of prose documents from non-WF text)
then SGML with short-references and minimization addresses the problem and
XML+compression+XML-hiding-text-editors do not.
(I had an interesting talk with a technical director of a multinational
publishing company recently, who told me that none of the problems they had
with SGML were solved by XML: in fact, XML got rid of the bits of SGML they
needed! And my friends at Allette Systems (whose offices I now use), seem
to be selling as many SGML courses as they ever have. So it will be
interesting if SGML turns out to maintain its niche, against all the hype.)
Cheers
Rick Jelliffe