[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML Schema 1.1 Best Practice: Expressing Local Constraints,i.e., Bu
Hi Folks, Suppose a community defines an XML vocabulary for purchase requests. Here is a sample purchase request: <purchase-request> <item>Widget</item> <cost>1500</cost> <signature-authority>Level1</signature-authority> </purchase-request> The community creates an XML Schema for purchase requests: <element name="purchase-request"> <complexType> <sequence> <element name="item" type="Name"/> <element name="cost" type="nonNegativeInteger"/> <element name="signature-authority"> <simpleType> <restriction base="string"> <enumeration value="Level1"/> <enumeration value="Level2"/> <enumeration value="Level3"/> </restriction> </simpleType> </element> </sequence> </complexType> </element> Members of the community create and exchange purchase requests conforming to the XML Schema. However, each member may have additional, local constraints they need to impose on purchase requests. For example, one member has this business rule: Level 1 managers can only sign off on purchase requests under $10K. Below are two approaches that the member may use to enforce its business rule. ------------------------------------ APPROACH #1: Override and Constrain ------------------------------------ One approach is for the member to create an XML Schema that overrides the element declaration for purchase-request. The XML Schema contains an <assert> element which expresses the business rule: <override schemaLocation="purchase-request.xsd"> <element name="purchase-request"> <complexType> <sequence> <element name="item" type="Name"/> <element name="cost" type="nonNegativeInteger"/> <element name="signature-authority"> <simpleType> <restriction base="string"> <enumeration value="Level1"/> <enumeration value="Level2"/> <enumeration value="Level3"/> </restriction> </simpleType> </element> </sequence> <assert test="(po:signature-authority eq 'Level1') and (xs:integer(po:cost) lt 10000)"/> </complexType> </element> </override> Using this approach the member validates purchase request XML instance documents against its own XML Schema, not the community-defined XML Schema. ---------------------------------------------- APPROACH #2: Supplement and Pipeline Validate ---------------------------------------------- A second approach is for the member to create a supplementary XML Schema that expresses the business rule: <element name="purchase-request"> <complexType> <sequence> <any maxOccurs="unbounded" processContents="lax" /> </sequence> <assert test="(po:signature-authority eq 'Level1') and (xs:integer(po:cost) lt 10000)" /> </complexType> </element> Using this approach the member validates purchase request XML instance documents against the community-defined XML Schema as well as its own supplementary XML Schema. An alternative to the supplementary XML Schema is to use Schematron. Those are two approaches. What other approaches could the member use to implement its local business rule? /Roger
[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
|