[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: (My) Feeling About SML
----- 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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|