[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Evaluation Criteria for Markup Languages
On Sun, 28 Aug 2011 18:17:58 -0400, "Costello, Roger L." <costello@mitre.org> wrote: > Hi Folks, > > I propose the following two criteria for evaluating XML markup > languages. This seems like a very 1980s kind of discussion to me, a rehash of LISP v C v 4GL and so on. Can we skip forward to 1991 and Gabriel's Worse is Better? The Wikipedia article is a good place to start. If an interface (i.e. the markup language syntax,or component model, or seemingly oddball rules eg UPA) is made more complex in order to support some simplification of implementation (e.g. so that you can implement it with a DFA) it may *look* more complicated but in fact be a net win. When you are talking about markup languages with processing semantics (such as schema languages, graphics and styling languages) then implementation considerations are part of the picture: I might dislike XML Schemas for many reasons, but XSD confining itself to a particular streaming/DFA processing model is not one of them (which is different from looking at how much bang per buck they get within those confines of course). Or take the case of using XPaths in schema languages: Schematron allows full XPath2 which is very complex, but it is trivial to implement since the libraries are available and high quality; XML Schemas 1.1 has a subset of XPath which looks simpler, but it needs to be specially implemented (subset parser, checks in the parser, a streaming implementation, extra education, etc) from scratch: the interface simplification means an implementation complexification! Or skip forward to 1999 and http://oreilly.com/catalog/opensources/book/larry.html Cheers Rick Jelliffe P.S. In fact, Worse is Better was in my mind when designing Schematron: the implementation is simple, it didn't have a mechanism for coping with exceptions such as when a document() function has an error nor any extra XPath functions added, it didn't need to have nested cases but could be flat, it didn't need to do what grammars do. 12 years later, and Schematron is being used more than ever, as far as I can tell, having found niches in publishing, finance, national security.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|