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

[Ghislain Fourny <g@28.io>]

Hi Mike,

I agree with you on this.

I think that, in the bigger picture, this tension between use cases
and orthogonality is also (or should be) reflected in how projects are
managed and how discussions with customers or the product manager are
driven.

A customer has needs, concrete problems and use cases to solve. I
think that there is, in addition to solving these, some kind of duty
to this same customer to make sure that the implementation has as much
orthogonality as possible, and to take the time to deeply understand
what the use cases really mean on a more abstract level -- even if it
may have the appearance of a short-term conflict. On the longer term,
it saves time, effort, as well as the customer's money.

It's Henry Ford saying "If I had asked people what they wanted, they
would have said faster horses.”

Kind regards,
Ghislain


On Mon, Jun 8, 2015 at 1:10 AM, Michael Kay <mike@saxonica.com> wrote:
>>
>> [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
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php