[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Separate data from rules ... is the XML Schema 1.1 <assert
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 **************************************************************** [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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|