> 
> Everytime something like this comes up our community winds up 
> rediscovering or rediscussing the same tradeoffs. 

And I think the overall experience of language design over the last 50 years
is that in the end, orthogonality is in everyone's best interests: both
implementors and users, not to mention standardizers. Orthogonality means
that wherever you can use an XPath expression (or a SQL expression or a
boolean expression or an arithmetic expression) you can use any XPath
expression (or SQL, etc).

For the user, othogonality provides predictability: you only have to do the
learning once, you only need one reference book, you can cut and paste code
that works in one place and use it in a different place. If a boolean
constraint works in your XForms interface and you want to apply it at the
database level instead, you just pick it up and move it.

For the vendor, orthogonality provides reuse: if the language is the same
regardless where it appears then you only have to implement it once, and you
can get by with a much smaller number of tests. (But I don't think the
vendor's interests should matter anyway. What's good for the user is good
for the vendor.)

SQL, if I remember right, went through the same agonies 30 years ago.
Initially they tried to do integrity constraints using a very small language
for writing conditional expressions, that didn't even allow arithmetic.
Eventually they ended up allowing you to write integrity constraints using
the full power of the SQL language. Most of the last 30 years, in fact,
they've been trying to make the language more orthogonal. Surely we're not
going to make the same mistakes again?

Michael Kay
http://www.saxonica.com/


From ht@i... Wed Feb 07 12:43:53 2007
Received: from aji.w3.org ([