[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Evaluation Criteria for Markup Languages

  • From: rjelliffe <rjelliffe@allette.com.au>
  • To: "Costello, Roger L." <costello@mitre.org>
  • Date: Mon, 29 Aug 2011 01:39:54 -0700

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.