• From: bryan rasmussen <rasmussen.bryan@g...>
• To: xml-dev@l...
• Date: Tue, 7 Jul 2009 15:19:16 +0200

Hi,

A propos the discussion of what is a business rule and what is a
structural rule, and what is the best practice in schema design..

First one of the driving design goals of XML Schema has been to
provide a state machine like validation mechanism, and often when
discussions of Schematron vs. XML Schema comes up high level arguments
about the halting problem often come up.

Currently XML Schema should not be prone to the halting problem, and
other technologies may well be. I suppose this is useful although for
me I don't have that many problems where it actually comes into
play...

so if this is the appropriate design constraint for XML Schema to have
it is obvious that some forms of validation will never be possible
within XML Schema.

I have to agree with the earlier statement that the difference between
the different types of rules is fuzzy, I would say because the
difference has to do with something that I haven't seen discussed in
the thread yet - although it may have been as longer threads can drop
info..

In fact I think the difference is not between structural rules and
business rules but rather validity rules and business rules.

To me the difference is that business rules are internal to an
organization that determine the workflow that must exist for
processing messages with an acceptable degree of validity,

While Validity rules are those rules that encode legal requirements
for message exchange in your particular industry.

As an example consider the aforementioned Managers of a certain level
can only sign for contracts of 10,000 euro or under (to paraphrase)

Validity rules are - all contracts must have signatures, signatures
must be by employees of the company the contract is with that were
employed on the date that the contract was issued..

Now a document comes into the system in which a manager of level 1 who
is an employee of the company has signed for 12,000 euro.

Legally this is a 'valid' document, we do not want to have it judged
not valid by our system and a response sent saying hey you're sending
non valid stuff because we may be opening ourselves up to legal
liability by not operating on the a completely legal document.. what
the business rule does is say we have a valid document that must be
handled in a process outside our normal process of 'pay off the
contract'....
(I suppose this is as apparent to everyone else as it is to me, sorry
if I belabor the obvious but I thought the discussion obfuscated this
point)

The reason to not do business validation in XML Schema is not that you
shouldn't mix these rules though, but rather that if you fail XML
Schema validation you don't have a good enough control of error
reporting to determine if a business rule or a validation rule has
failed - thus if you are using XML Schema rules you should have your
validation rules in the Schema and some other rules in a some other
form whereby you have better control of output - actually though one
could conceive of a system where the XML was validated twice by XSD -
once with XML Schema with validation rules, again with XML Schema with
those same rules but also business rules. Because you fail the first
Schema you are 'valid' because you fail the second Schema you are sent
to further processing

Please note that while I say one could conceive of should a system the
conception is not meant to be a suggested model.

Cheers,
 Bryan Rasmussen