(My) Feeling About SML

[Michael Champion]

----- Original Message -----
From: Leigh Dodds <ldodds at ingenta.com>
To: xml-dev <xml-dev at ic.ac.uk>
Sent: Wednesday, November 17, 1999 6:00 AM
Subject: (My) Feeling About SML


>
> So this leads me to the conclusion that a simplified API, perhaps
> coupled with a means to define the XML feature subset of a schema
> would address 99% of the issues raised thus far.

I agree.  I'm *interested* in "SML" for small devices and high throughput
devices, but I agree that the speed/size benefits for processors of
stripping down the spec remains to be proved.  I just want to see some
evidence before dismissing the possibility.

My main interest here is in stripping down the DOM API for small devices.
We *know* that many of the features apply mostly to browsers and are
overkill for servers, PDAs, etc.  Of course the DOM WG or somebody else
could define a "SDOM" API . The problem is that without guidance from some
"SML" spec, it's not at all clear what interfaces to remove.  Should, for
example,  the DOM WG (or the SDOM Mafia, or whoever) just decide on their
own that external parsed entities are "evil" and should not be supported in
"SDOM"?  There's clearly no way for the API used by a message receiver to
control or even negotiate the set of XML features used by the sender.  So an
"SDOM" API without some spec or meta-spec defining the subset of XML to
employ is not likely to be terribly useful.

But, as you say, if there was a means to define the XML feature subset, as
an add-on to the XML spec rather than a separate "SML" spec, then various
"SDOM" activities could go forward by simply deciding on the feature subset
that a particular API would support.

So, we NEED stripped down DOM-like APIs for small and high-throughput
platforms ... a formal means to define an XML feature subset would help
specify when the stripped down APIs are appropriate. There *may* also be an
overall speed benefit for the stripped down processors handling the
stripped-down XML subsets, but this remains to be proven.

Mike Champion

(p.s. OK, we don't "need" DOM-like APIs, we could use SAX ... but many of us
find the DOM abstractions to be more useful.  Also, there's a new generation
of tools to generate Java or C++ classes directly from schemas that further
abstract the API from the XML data.  It's not clear to me whether these will
have to wrestle with the SML issues or whether, for example, the lack of
entity declarations in a DTD will imply that no entity resolving code is
generated ... in any event, I think a formal XML feature subset mechanism
would simplify these code generation tools as well as the DOM-like APIs.)


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)