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

Language design, orthogonality, paternalism, bad rules, and elephanttrap

  • From: Roger L Costello <costello@mitre.org>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Wed, 2 Mar 2022 14:39:30 +0000

Language design

It has been a longstanding tradition in the SGML and XML community to express ID and IDREF values using attributes. In fact, DTD (which predated XML Schema) did not allow elements to be of type ID or IDREF; only attributes could be of type ID and IDREF.

When XML Schema was created they decided to allow both attributes and elements to be of type ID and IDREF. Why? Is there a compelling use case for declaring elements to be of type ID and IDREF? No. So why did they do it?

The answer is orthogonality. Michael Kay explains:

“Orthogonality (or, "no needless restrictions") says the lack of a use case is not a reason to disallow it.”

 

“The concept of preventing you doing something because the language designers didn't think it was a sensible thing to do was known in the XML Schema working group as ‘paternalism.’ An example of paternalism would be to disallow --1 (minus minus one) in XPath; or in regular expressions to disallow overlapping ranges [a-zi-k]. In my view, a rule that exists solely to prevent you doing something that's well-defined but useless is usually a bad rule. Another example is the rule that concat() must have at least two arguments: I think that's a thoroughly bad rule.”

 

“Of course there's a very fine line between paternalism and things like type-checking rules that are designed to protect programmers from their own errors. XPath 1.0 allowed you to write -1 < 0 < +1, and the result is false (because -1 < 0 is true, and true < 1 is false). XPath 2.0 disallowed that; a restriction that prevents you falling into an elephant trap isn't the same as a restriction that stops you writing expressions that aren't useful. But XPath 2.0 doesn't stop you writing @x/@y: that's justified by orthogonality, but it's almost certainly a mistake. I think we should have made that a type error.”

 

“Bottom line, I think:

 

(a) Don't sacrifice orthogonality (introduce restrictions) just because something has no known use case

 

(b) But do (sometimes) sacrifice orthogonality to stop users falling into elephant traps.”



[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.