Re: [xml-dev] Evaluation Criteria for Markup Languages

[rjelliffe <rjelliffe@allette.com.au>]

 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.