SML answers for SML problems

[Don Park]

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.

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.  On appliance-level devices, even 5K difference in size
translates to significant manufacturing cost increase because
memory size does not increase in friendly increments.  On network
routers and proxies, even a few microseconds delay can mean
significantly reduced load capacity.  There are no talk of
'documents' on these type of applications.

2) Simpler and easier

Based on my experiences in 'spreading the XML religion', I
find that XML is easy to learn but it is hard to learn
completely.  Key ideas behind XML is strikingly simple yet
most people get confused by things like DTD, PI, notation,
comment, entity, XML declaration, whitespace rules, character
encoding, etc.

One of the goals for SML should be:

    SML is what people think XML is.

By people, I mean the engineers understand the key concepts
behind XML but have not yet been spoiled by the hairy details.
SML should fit the mental model of XML people build when they
first hear about XML.

I believe that an engineer can not use a tool fully unless
he/she understands the tool completely.  Perhaps it is a
peace of mind, perhaps it is confidence.  Whatever the reason,
it is important that there is a clear mental picture of the
tool and its capabilities.  Having a clear spec is great but
having to refer back to it frequently is not good in my book.

SML will be simpler and easier to learn completely.  Question
is whether there is truely a need for simpler and easier XML.

3) Data versus Documents

A good part of XML 1.0 is designed to address document
processing problems.  Those parts fails to apply when XML data
exists only in transit (WebDav, XML-RPC, SOAP), has no end
(continuous broadcast), or is sent one-way only.  While the spec
for such applications might list the unsupported features of XML,
I believe it is easier to just say the spec uses the SML subset.

4) Friend or foe?

Is SML a friend or foe of XML?  Many folks brought up this
question either directly or indirectly.  I happen to think
SML will eventually help rather than hurt adoption of XML but
the media might have a field-day with SML vs. XML articles.

My thought at this point is that SML is needed by a subset of
the XML community.  Creating a subset of XML for subset of XML
community seems like a reasonable thing to do.

Best,

Don Park    -   mailto:donpark at docuverse.com
Docuverse   -   http://www.docuverse.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)