Re: SGML, XML and SML
"Don Park" <donpark@d...> writes: > As I am not allowed to use the XML 1.0 spec to create the SML spec > without review by W3C, I have started writing from scratch so it > might take a bit of time. Once the first draft is up, we can start > arguing about the specifics. Obviously you cannot cut and paste, but I see no reason that SML cannot refer to the XML 1.0 spec just as any other XML-based spec (W3C or otherwise) can. That's only fair. The problem is not whether SML documents will be XML or not (they probably will), but whether processors that handle SML and not XML will be XML processors (they definitely won't). What killed SGML for me and my customers was a lack of adequate software support in Web languages (Java and Perl) and a brilliant but extremely complex and mostly undocumented library in C++ (SP). With identical software support, I very much doubt that SGML's extra complexity would have cost my customers any extra time or money at all, or that SML's extra simplicity would save them any. > Since I have already made a statement to the effect that I'll eat > the SML spec if it doesn't fly, I am most keen to keep the spec > short enough to digest easily (literally :-). The problem with SGML was that almost no one except James Clark or a well-funded university research project had the time and energy to create the SGML libraries in the first place (I know, I tried to do it in Java). By comparison, I had AElfred doing useful parsing in the first couple of hours, and could handle most documents in a couple of days (adding character set support and tuning the performance took a little longer) -- it was an order of magnitude simpler to write an XML parser than it was to write a general SGML parser. So, for SML to fly, it will not only have to be another order of magnitude easier to implement than XML (which is entirely possible), but that order of magnitude will have to cross a significant theshold. We already have more than adequate free XML parsing support in Java, C, C++, Perl, Python, Tcl, etc. etc., so SML doesn't buy us anything (the cost of using an existing free parser is 0, and SML cannot possibly take less than 0 to implement). In other words, to keep paper and printer ink out of his diet, Don will need the following two things to happen: 1. there will have to be an important new platform or language without existing XML support; and 2. the difference in cost and time of implementing XML support on that platform will have to clearly outweight the advantages of interoperability. It is entirely possible that small devices like cell phones could be just such a platform, but I'm not convinced -- a simple, non-validating XML parser takes only a few days to write and debug, the difference between a few person-days and a few person-hours won't usually justify abandoning the enormous benefit of interoperability. People have put forward arguments about memory usage, but those were all trivially easy to answer, so we're still dangling. Of course, I've been wrong often before, and I'm not an expert in small or embedded devices, so I'll look forward to seeing what happens. I do think that small devices will be at the centre of computing in the next decade (and a mostly MS-free centre, to boot). I'm also looking forward to the big 3COM antitrust trial in 2009. All the best, and good luck, David -- David Megginson david@m... http://www.megginson.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