SGML, XML and SML

[David Megginson]

"Don Park" <donpark at docuverse.com> writes:

> As I am not allowed to use the XML 1.0 spec to create the SML spec
> without review by W3C, I have started writing from scratch so it
> might take a bit of time.  Once the first draft is up, we can start
> arguing about the specifics.

Obviously you cannot cut and paste, but I see no reason that SML
cannot refer to the XML 1.0 spec just as any other XML-based spec (W3C
or otherwise) can.  That's only fair.

The problem is not whether SML documents will be XML or not (they
probably will), but whether processors that handle SML and not XML
will be XML processors (they definitely won't).

What killed SGML for me and my customers was a lack of adequate
software support in Web languages (Java and Perl) and a brilliant but
extremely complex and mostly undocumented library in C++ (SP).  With
identical software support, I very much doubt that SGML's extra
complexity would have cost my customers any extra time or money at
all, or that SML's extra simplicity would save them any.

> Since I have already made a statement to the effect that I'll eat
> the SML spec if it doesn't fly, I am most keen to keep the spec
> short enough to digest easily (literally :-).

The problem with SGML was that almost no one except James Clark or a
well-funded university research project had the time and energy to
create the SGML libraries in the first place (I know, I tried to do it
in Java).  By comparison, I had AElfred doing useful parsing in the
first couple of hours, and could handle most documents in a couple of
days (adding character set support and tuning the performance took a
little longer) -- it was an order of magnitude simpler to write an XML
parser than it was to write a general SGML parser.

So, for SML to fly, it will not only have to be another order of
magnitude easier to implement than XML (which is entirely possible),
but that order of magnitude will have to cross a significant theshold.

We already have more than adequate free XML parsing support in Java,
C, C++, Perl, Python, Tcl, etc. etc., so SML doesn't buy us anything
(the cost of using an existing free parser is 0, and SML cannot
possibly take less than 0 to implement).  In other words, to keep
paper and printer ink out of his diet, Don will need the following
two things to happen:

1. there will have to be an important new platform or language without
   existing XML support; and

2. the difference in cost and time of implementing XML support on that 
   platform will have to clearly outweight the advantages of
   interoperability.

It is entirely possible that small devices like cell phones could be
just such a platform, but I'm not convinced -- a simple,
non-validating XML parser takes only a few days to write and debug,
the difference between a few person-days and a few person-hours won't
usually justify abandoning the enormous benefit of interoperability.
People have put forward arguments about memory usage, but those were
all trivially easy to answer, so we're still dangling.

Of course, I've been wrong often before, and I'm not an expert in
small or embedded devices, so I'll look forward to seeing what
happens.  I do think that small devices will be at the centre of
computing in the next decade (and a mostly MS-free centre, to boot).
I'm also looking forward to the big 3COM antitrust trial in 2009.


All the best, and good luck,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)