RE: Feeling good about SML
On Tue, 16 Nov 1999, Don Park wrote: > 1. SML shall be easier to learn than XML > > Ideally, one should be able to learn the ins and outs of SML > COMPLETELY within 30 minutes. Amount of time spent is not > important but it can be used to indirectly measure the level of > required attention span, mental model complexity, amount of > details one must remember, etc. Learn by whom? Learn at what level? Consider that the formal specification of a language, to be useful, has to be written extremely precisely. Yet the very precision needed will make a specification hard to read by people who aren't used to reading formal specifications. Do we need the complete specification to be completely understandable in 30 minutes to someone who's never read a spec before? Someone with no background in logic, math, computer science, physical science, philosophy? Keep in mind that a comma-separated format for variable-length data is conceptually quite simple, yet there are plenty of incompatible CSV formats and brain-dead CSV parsers out there. Sometimes "easy to learn" really means "A developer unfamiliar with the tool can start off at 100% productivity without having to acquire any knowledge that would allow him to command a higher salary," i.e. "easy for a developer to learn" really means "easy for a manger to Taylorize." I should also point out that the amount of learning required to be able to *implement* a tool is almost always greater than the amount of learning required to be able to *use* that tool. The XML Recommendation, for example, is daunting reading for a lot of people because it describes the language in the terms an implementor needs. But people who are merely going to use XML vocabularies, rather than implement XML parsers, need not master the whole thing. Think of an XML parser as a device driver. An application programmer needs to know how to use a device driver, but not how to write one. > 3. SML shall be easier to implement than XML > > It should be possible for an average engineer to write a fully > compliant SML parser within a week. While there are many XML > parsers out there now, level of compliance is questionable and > amount of time and effort to implement them is greater than > originally intended for XML. I question why this is important. Writing a parser is essentially a system programming task, not an application programming task. It will be done very infrequently compared to writing code that uses the parser. To me, the main "benefit" of this requirement seems to be to make it possible for applications programmers to roll their own parser each time they write an application rather than re-using a standard piece of code. The claimed benefit for this is usually that roll-your-own code can be more "efficient" than general-purpose code, but that "efficiency" is usually nothing more than micro-optimization. Such claims seldom take total cost into account; every roll-your-own parser has to be tested and debugged, and cutting corners with those activities doesn't reduce your bottom-line costs; it just smears those costs among several line-items rather than giving them a line of their own. This requirement comes off to me as a political concession to support NIH cultures. 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