[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] SML answers for SML problems
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@d... Docuverse - http://www.docuverse.com 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
|