[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: (My) Feeling About SML

  • From: "Michael Champion" <Mike.Champion@s...>
  • To: "xml-dev" <xml-dev@i...>
  • Date: Wed, 17 Nov 1999 09:43:12 -0500

my feeling

----- Original Message -----
From: Leigh Dodds <ldodds@i...>
To: xml-dev <xml-dev@i...>
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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.