Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Michael,
> > First an example of a business rule:
> >
> > A Level 1 manager has a maximum signature
> > authority of $10K.
> >
> > An auto loan applicant, living in Ohio, is
> > underage if he/she is under 18 years of age.
> >
> > If a customer has no outstanding invoices,
> > then the customer is of preferred status.
> >
> I agree those are business rules and are best kept out of a schema.
I am concerned that schema designers will not recognize that this is bad practice:
<element name="Level_1_Manager_Signoffs">
<complexType>
<sequence>
<element name="purchase-request" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="item" type="string" />
<element name="cost" type="decimal" />
</sequence>
</complexType>
</element>
</sequence>
<assert test="purchase-request/cost lt 10000"/>
</complexType>
</element>
How will a schema designer distinguish between "structural rules" versus "business rules?" (And put the former into XML Schema but not the latter)
What is a "structural rule?"
In XML Schema 1.0 the answer was clear: anything that required computation, if-then-else logic, inference, and co-constraints could not be placed in XML Schema, and was therefore placed in Schematron) All rules were expressed and managed by Schematron.
The XML Schema 1.1 <assert> element adds confusion to the task of building schemas:
Is this a structural rule or a business rule?
Should I express this using <assert> within
XML Schema, or manage it separately in a
rules document?
What do you think?
/Roger
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
