Re: [xml-dev] Use-cases are the bane of orthogonality

[Michael Kay <mike@saxonica.com>]

> 
> [Definition] Orthogonality: if a tool is orthogonal, it can be added, replaced, or removed, in favor of better tools, without screwing everything else up. The classic example is Unix command line tools: you have one tool for getting the contents of a disk (dd), another for filtering lines from the file (grep), another for writing those lines to a file (cat), etc. These can all be mixed and matched at will. [1]
> 

I think we should be able to do better than this definition.

If we think of the mathematical meaning of “orthogonal”, I think the idea is that the system has a number of design parameters and these can be selected independently of each other. So for example if you have a system that supports four data models (DOM, JDOM, XOM, AXIOM) and three APIs (XPath, XSLT, XQuery) then it should be possible to use any of these data models with any of these APIs. There may be no use case for running XQuery over XOM, but you should do it in the interests of orthogonality.

The UNIX pipe operator is orthogonal because the command used as its left-hand operand can be chosen independently of the command used as its right hand operand. So this is an example of the general principle; but I think the definition you cite fails to state the general principle. 

For a debate about use-cases versus orthogonality that is highly topical, consider the need to design a query language that can handle both XML and JSON. These are two use cases. A design with maximum orthogonality can handle all the primitives that occur either in XML or in JSON in any combination, not only in the combinations that arise with XML and with JSON; for example it can handle arrays whose members are nodes.

Michael Kay
Saxonica