SML answers for SML problems

David Megginson david at
Fri Nov 12 11:51:17 GMT 1999

"Don Park" <donpark at> writes:

> There were many points raised in the initial discussion of
> the SML idea:
> 1) Smaller and faster
> I think everyone can agree that SML parsers will be smaller
> and faster than XML parsers due to removal of features.  What
> remains controversial is whether the difference is significant
> enough to justify SML.  Since we do not have SML parsers to
> compare XML parsers with, we are left with only extrapolations
> and guessworks.

And anecdotal evidence.  I've mentioned my own experience with
AElfred, which was a recursive descent parser.  Since the lexical
routines for reading names, etc. already had to be in place, handling
PIs and stuff like that was trivial.  Here's what Matt Timmerman's
current version has:

  void parsePI ()
    throws java.lang.Exception
    String name;

    name = readNmtoken(true);
    if (!tryRead("?>")) {
    if (handler != null) {
      handler.processingInstruction(name, dataBufferToString());

> My assessment is that the difference is not significant for
> general XML applications.  However, the difference is important
> for XML applications that places a high premium on size and/or
> speed.  

Even on an embedded system, I doubt that the few bytes added by the
above example would amount to anything -- of course, a parser
implemented as a state machine might need more or less overhead.

The support for attributes is a little longer, but not all that much.
We're not talking about 5K here -- that comes from detecting all of
the well-formedness errors required for conformance and storing the
text of their messages.

All the best,


David Megginson                 david at

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

More information about the Xml-dev mailing list