Re: [xml-dev] Separate data from rules ... is the XML Schema 1.1 <assert

["C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>]

On 17 Jun 2009, at 11:42 , Costello, Roger L. wrote:

>
> Hi Folks,
>
> Here's a recap of what I've learned from this very illuminating  
> discussion:
> ...
> Non-structural rules are business rules. Business rules should be  
> not expressed in XML Schema.


I don't think you learned that from this discussion;
you were making that assumption at the outset.

What I have learned from this discussion is:

    - Some people think there is a clear distinction
      between structural rules and business rules.

    - They do not, however, seem to be able to explain it
      clearly or usefully.

    - Some people think that if there are two different
      kinds of rules, they should be expressed in two
      different languages.

    - They don't seem to feel any need to provide a
      reason to believe this.

    - Some people believe that existing languages for
      defining document validity have different expressive
      power because they were designed for different
      kinds of rules (or: because they are suitable
      for different kinds of rules, through accidents
      of history that have nothing whatever to do with
      design).  I know that this belief is false as it
      regards conscious design; I believe it to be
      false (or at least unsupported by any serious
      evidence) as regards actual suitability of the
      languages.

I have, that is, learned a lot about the ability of humans
involved in IT and business to hold strange and wonderful
opinions that seem to me to be wholly unrelated to reality,
argument, or evidence.

Nothing in the discussion has provided any evidence in favor
of the proposition that there is a clear distinction to
be made between "business rules" and "structural rules".
The examples that have been adduced in an attempt to
clarify the difference have seemed to me to provide
convincing evidence that the distinction is in the eye
of the beholder, not in the nature of the rule.  The
examples that have been adduced to show that the distinction
is sometimes fuzzy seem to me to show that it is indeed
sometimes fuzzy (and perhaps that it is ALWAYS fuzzy).

Nor has anyone provided any reason to support the claim
which you postulated at the outset, and repeat above, that
if two different kinds of rules can be distinguished,
then they should be expressed in different languages.

In any given system, there may well be some rules which
need to be easily changed without replacing the system,
and other rules which can be built into the system at a
deep level (and thus made very hard to change).  There may
well be different sets of rules for which different
groups in an organization need to be responsible; one
possible way to allow different people to own different
sets of rules is to put their rules into different
documents with different maintenance and update patterns.
Those different documents can (but need not) be in
different languages; since different groups in any
organization may have different skills, different ways of
thinking about and organizing the world, they may find
different languages 'natural'.

The most plausible reason to distinguish "business rules"
from "structural rules" that I can see is that there are
some rules which an organization may frequently want to
change, for reasons of business strategy and tactics, and
others which they don't expect to want to change frequently.

If the non-technical people in an organization find a
particular language hard to understand (whether it is
XSD or XSLT or SQL or the language of the local tax code),
they will push to have they rules they want to change
frequently expressed in some other language.  That makes
a certain amount of sense, if we assume that they have
given up on getting fast turnaround on anything from their
IT department and thus want to be able to make the changes
themselves.  It may make the situation more palatable if
someone makes up a story about how certain kinds of rules
SHOULD be expressed in this or that language, but as far
as I can tell from the examples you have given, the real
function of that story is to allow people to think that the
pattern of organization they have fallen into is a natural
law and avoid thinking about the flaws in their relation
to their IT department.

In some organizations, where XSD schemas are deployed at
relatively low levels and may be hard to change (as in
some schema-aware database systems or in distributed systems
which cannot change their schemas easily), it will make sense
to put only unchanging rules into the XSD schemas installed
at the low level, and to put other rules, which may change
more frequently, into other constraint documents:  Schematron
rules, or code books, or DTDs, or additional XSD documents,
or ....

And conversely, when a system is built on certain
assumptions taken as bedrock, it can make sense to try
to ensure that it's not easy for anyone to try to
change those assumptions.  (If large parts of the system
assume that every part in the parts catalog has a part
number, and are built to rely on that assumption, then
you don't want some new hire casually decreeing that
from now on part numbers are optional.)

If there are any rules which seem unlikely to change as a
result of a change in business tactics, then one of them
is the rule that meetings cannot end before they start.

If any line of analysis leads to the conclusion that the
rule about start and end times needs to be treated
as a "business rule" so that it can be changed frequently,
then that line of analysis is self-evidently zany and
can safely be regarded as one more bit of evidence that
your large organization really does have a Humor Department.
I respectfully suggest that your analysis, which if I
understand your email did lead to that conclusion, is
in need of re-thinking.

Michael Sperberg-McQueen


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************