[Accessibility conventions are described at the bottom of the page]

6. Controlled vocabulary association detail
[> 7.][< 5.3.2][^^^]
6.0 Controlled vocabulary association detail
[> 6.1][> 7.][< 6.][^^][^^^]
CVA files are validated using an W3C Schema expression of constraints
[[1] - /xsd/ContextValueAssociation.xsd
[[2] - includes /xsd/xml.xsd
]]
Development work still in progress
[[1] - the work is continuing by the OASIS technical committee
 [1] - needs more community input and practice before becoming version 1.0
]
6.1 Context/value association files
[> 6.2][< 6.0][^^][^^^]
6.1.1 Context/value association vocabulary
[> 6.1.2][> 6.2][> 7.][< 6.0][^^][^^^]
<ValueListConstraints>
[[1] - document element
 [1] - temporary namespace "http://docs.oasis-open.org/codelist/ns/ContextValueAssociation/cd2-1.0/"
[[2] - used only during committee draft specification development
 [2] - when finalized will probably end with "/1.0/"
][1] - name=
[[2] - (mandatory name token) used to name the Schematron pattern created for these associations
][1] - optional <Title>, <Identification>, <Description> and <Include> children
 [1] - mandatory <ValueLists> and <Contexts> children
 [1] - id=
[[2] - (optional URI) used to give this resource a unique identifier
][1] - version=
[[2] - (optional) documentary information indicating the version of this resource
][1] - queryBinding=
[[2] - (optional) an indication of the addressing language used for document contexts
 [2] - when not specified, it is up to the implementation to assume what the document context addressing language is
]]
<Annotation>
[[1] - (optional) used to annotate the resource as a whole
 [1] - mixed content with foreign vocabularies is allowed to be used for both children
 [1] - <AppInfo>
[[2] - (optional) an annotation targeted for downstream processing by an application
][1] - <Description>
[[2] - (optional) an annotation targeted for downstream reading by a human
]]
<Title>
[[1] - (optional) value used in reports for titling information regarding the associations
 [1] - mixed content with foreign vocabularies is allowed to be used
]
<Include>
[[1] - (optional and repeatable) directive used to include rules from another value list context association file
[[2] - important for the management of many context and value associations
 [2] - the including CVA file constraints have priority over included CVA file constraints for the same document context
][1] - uri=
[[2] - (mandatory) location of the file
][1] - <Annotation>
[[2] - (optional) annotations related to this directive
]]
<ValueLists>
[[1] - (mandatory) collection of pointers to external representations of value lists
 [1] - <Annotation>
[[2] - (optional) annotations related to this construct
]]
<ValueList>
[[1] - (optional and repeatable) pointer to external representation of value lists
 [1] - xml:id=
[[2] - (mandatory) unique identifier for this pointer to a resource
][1] - uri=
[[2] - (mandatory) external URI for this resource
][1] - key=
[[2] - (optional) identification of the key identifier in the genericode file for code lookup
][1] - <Annotation>
[[2] - (optional) annotations related to this construct
][1] - optional <Identification> child (at most one)
 [1] - mixed content with foreign vocabularies is allowed to be used for documentation
]
<Identification>
[[1] - (optional) this child of <ValueList> defines masquerading meta data that overrides corresponding meta data found in the external file with the following optional child elements:
[[2] - <Annotation>
[[3] - (optional) annotations related to this construct
][2] - <ShortName>
 [2] - <LongName>
 [2] - <Version>
 [2] - <CanonicalUri>
 [2] - <CanonicalVersionUri>
 [2] - <LocationUri>
 [2] - <AlternateFormatLocationUri>
 [2] - <Agency><ShortName>
 [2] - <Agency><LongName>
 [2] - <Agency><Identifier>
][1] - the <Identification> element uses the identical element structure (with names in the context/value association namespace rather than no namespace) such that one can copy and paste the <Identification> element from a genericode file
[[2] - note per XML rules, when the context/value association namespace is assigned to a prefix, each of the elements copied will need to be prefixed
]]
<Contexts>
[[1] - (mandatory) collection of information item contexts
 [1] - <Annotation>
[[2] - (optional) annotations related to this construct
][1] - optional <Context> children
]
<Context>
[[1] - a single information item context
 [1] - values=
[[2] - (mandatory) space-separated pointer to unique identifiers of external value list representations associated with the information item in context
][1] - item=
[[2] - (mandatory) XPath location step for information item
 [2] - either "ElementName" or "@attributeName" identifying the information item without any context
][1] - scope=
[[2] - (optional; mutually exclusive with address=) ancestral context for the item
 [2] - does not make reference to the information item itself, only the ancestor of the information item
][1] - address=
[[2] - (optional; mutually exclusive with scope=) specific XPath location path context for the information item
 [2] - must make reference to the information item itself as the rightmost location step
 [2] - this is used in circumstances where ancestral context is either insufficient or too encompassing
][1] - mark=
[[2] - (optional) a name token (no spaces) characterizing a violation of this context for downstream purposes
[[3] - can be used, for example, to distinguish warnings from errors
 [3] - no predefined semantics of the values being used
 [3] - a downstream process can base decision making on the nature of the mark on each violation
]][1] - <Annotation>
[[2] - (optional) annotations related to this construct
][1] - optional <Message> child (at most one)
 [1] - mixed content with foreign vocabularies is allowed to be used for documentation
]
<Message>
[[1] - (optional) a Schematron reporting message replacing the default generated message
[[2] - when a custom-worded message is needed when reporting a constraint violation
 [2] - typically this includes Schematron constructs such as <sch:value-of> with which a tailored message can retrieve neighboring information from the document context of the constraint violation
][1] - this element is ignored if it has no child elements or no non-white-space text strings
]
6.1.2 Using scope= or address=
[> 6.1.3][> 6.2][> 7.][< 6.1.1][^][^^][^^^]
System-wide context (all documents)
[[1] - don't use either scope= or address=
 [1] - the matching XPath address is simply the item= information item name
 [1] - example:
 [1] -
<Context item="@currencyID" values="currency">
[[2] - the currencyID= attribute is checked for the same values across all documents
]]
Single document-wide context
[[1] - use scope= with the document element
[[2] - does not include the specification of the focus item in the context expression
][1] - example:
 [1] -
<Context item="@currencyID" scope="/in:Invoice" 
         values="currencySell"/>
<Context item="@currencyID" scope="/po:Order"
         values="currencyBuy"/>
[[2] - the currencyID= attribute is checked with different values for orders than for invoices
]]
Sub-document context
[[1] - use scope= with an element other than the document element
[[2] - does not include the specification of the focus item in the context expression
][1] - example:
 [1] -
<Context item="cbc:CountrySubentityCode" values="provinces states"
         scope="cac:BuyerCustomerParty">...
<Context item="cbc:CountrySubentityCode" values="states"
         scope="cac:SellerSupplierParty">...
 [1] - the <cbc:CountrySubentityCode> element is checked with different values in different sub-trees in the documents
]
Narrow sub-document context
[[1] - use address= when using scope= is ambiguous
[[2] - requires the specification of the focus item in the XPath expression
][1] - very rarely needed, but important when a narrow specification is needed to disambiguate a broad specification
 [1] - example in support of the UBL document fragment below:
 [1] -
<Context item="cbc:ID" values="categoryIdentifiers"
         address="cac:TaxCategory/cbc:ID"/>
<Context item="cbc:ID" values="schemeIdentifiers"
         address="cac:TaxScheme/cbc:ID"/>
[[2] - the <cbc:ID> element is checked in each explicitly-specified context
 [2] - the use of scope="cac:TaxCategory" is inappropriate because there are at least two cbc:ID values descendent from that element
][1] - note that the XPath address must be complete and include the target information item (found in item=) as the right-most step of the address (used in address=)
]
Consider the following UBL document fragment:
[[1] - note how the different <cbc:ID> elements are in overlapping sub-trees of the XML document
]
[Example 6-1:
01   ...
02   <cac:TaxTotal>
03   <cbc:TaxAmount currencyID="UYU">15.00</cbc:TaxAmount>
04   <cbc:TaxEvidenceIndicator>false</cbc:TaxEvidenceIndicator>
05   <cac:TaxSubTotal>
06   <cbc:TaxableAmount currencyID="USD">100.00</cbc:TaxableAmount>
07   <cbc:TaxAmount currencyID="USD">15.00</cbc:TaxAmount>
08   <cac:TaxCategory>
09   <cbc:ID>Z</cbc:ID>
10   <cbc:Percent>15</cbc:Percent>
11   <cac:TaxScheme>
12   <cbc:ID>Provincial Tax</cbc:ID>
13   </cac:TaxScheme>
14   </cac:TaxCategory>
15   </cac:TaxSubTotal>
16   </cac:TaxTotal>
17   ...
]
6.1.3 Value list specification, extension and restriction
[> 6.2][> 7.][< 6.1.2][^][^^][^^^]
Recall the overview of a context/value association file contents on [Context/value association specification - Section 5.1.3 Context/value association specification]
[[1] - value lists are declared pointing to external value list enumerations
 [1] - contexts associate an XPath document context with one or more value list declarations
]
Recall the depiction of extending and restricting lists on [Association specification, extension and restriction - Section 5.1.4 Association specification, extension and restriction]
[[1] - specification: simply pointing to the declaration of A
 [1] - extension/union: pointing to the declaration of the base list B and the declaration of the extension D
 [1] - restriction: pointing to the declaration of the restricted list D' that has masquerading meta data for the complete list D
]
[Example 6-2:
01  <ValueListConstraints id="..." name="..." version="...">
02   <AppInfo>...</AppInfo>
03   <Description>...</Description>
04   <Title>...</Title>
05   <Include uri="..."/>
06  
07   <ValueLists>
08   <ValueList xml:id="A" uri="A.gc"/>
09   <ValueList xml:id="B" uri="B.gc"/>
10   <ValueList xml:id="C" uri="C.gc"/>
11   <ValueList xml:id="DP" uri="DP.gc">
12   <Identification>...D meta data...</Identification>
13   </ValueList>
14   </ValueLists>
15  
16   <Contexts>
17   <Context item="..." values="A">..simple..</Context>
18   <Context item="..." values="B C">..extending/unioning..</Context>
19   <Context item="..." values="DP">..restricting..</Context>
20   </Contexts>
21  </ValueListConstraints>
]
6.2 Masquerading meta data
[> 6.3][< 6.1.3][^^][^^^]
6.2.1 Masquerading meta data
[> 6.3][> 7.][< 6.1.3][^^][^^^]
All different value lists should have unique list-level meta data identifying each list
[[1] - e.g. every code list published by UBL has unique meta data
[[2] - the supplied "pass 2" value validation checks instance-level meta data values against the list-level meta data
][1] - the list-level meta data identifies the list properties including the list's custodian
 [1] - e.g. the code list for currency values
]
The list-level meta data for the ISO currency code list is as follows:
[Example 6-3:
01  <Identification>
02   <ShortName>CurrencyCode</ShortName>
03   <LongName>Currency</LongName>
04   <LongName Identifier='listID'>ISO 4217 Alpha</LongName>
05   <Version>2001</Version>
06   <CanonicalUri>urn:un:unece:uncefact:codelist:
07  specification:54217</CanonicalUri>
08   <CanonicalVersionUri>urn:un:unece:uncefact:codelist:
09  specification:54217:2001</CanonicalVersionUri>
10   <Agency>
11   <LongName>United Nations Economic Commission for
12  Europe</LongName>
13   <Identifier>6</Identifier>
14   </Agency>
15  </Identification>
]
When restricting a published list, the restricted list has different meta data than the published list
[[1] - e.g. limiting the currency codes to only Canadian and US dollars
]
An example of list-level meta data for a reduced code list CAUS_CurrencyCode.gc is as follows:
[Example 6-4:
01  <Identification>
02   <ShortName>CAUSCurrencyCode</ShortName>
03   <LongName>Canadian and US Currency Codes</LongName>
04   <Version>1</Version>
05   <CanonicalUri>urn:x-company:CAUS-currency</CanonicalUri>
06   <CanonicalVersionUri>urn:x-company:CAUS-currency:1</CanonicalVersionUri>
07  </Identification>
]
Users specifying an item from the published list will typically be using for instance-level meta data the list-level meta data of the published list
[[1] - this ensures the XML document passes the supplied "pass 2" value validation checks for the published standardized document type
 [1] - alternatively trading partners may choose to require the meta data of the derived lists, though this "breaks" value validation against the standardized document type
 [1] - e.g. specifying a currency value with meta data from the published list of currency codes
[[2] -
<cbc:TaxableAmount currencyCodeListVersionID="2001"
                   currencyID="USD">100.00</cbc:TaxableAmount>
 [2] - the user is expecting to validate the document against the published code list constraints
]]
Masquerading meta data ensures a restricted list appears the same to validation as the published list
[[1] - the declaration of the external list of values incorporates the masquerading meta data in the declaration
[[2] - recall the vocabulary for the declaration of a value list shown on [Context/value association vocabulary - Section 6.1.1 Context/value association vocabulary]
 [2] - this doesn't disturb the meta data in the restricted external files
 [2] - trading partners can choose to use the declaration with or the declaration without the masquerading meta data
][1] - the following example of a declaration to a constrained list of currency codes is identical to the list-level meta data found in the original list
[[2] - simplest approach is just to copy the entire <Identification> element from the original list
[[3] - noting, of course, that the elements in the genericode file are in no namespace, but in the context/value association file they are in a namespace
 [3] - if the CVA file is using a prefix for the CVA namespace, the copied elements will need to have each of their names appropriately prefixed
 [3] - if the CVA file is using the default namespace for the CVA namespace, no changes are needed to the syntax
]]]
A declaration pointing to the reduced list while masquerading as the ISO list is as follows:
[Example 6-5:
01      <ValueList xml:id="currency" uri="CAUS_CurrencyCode.gc">
02   <Annotation>
03   <Description>
04   Restricted to only Canadian and US dollars.
05   </Description>
06   </Annotation>
07   <Identification>
08   <ShortName>CurrencyCode</ShortName>
09   <LongName>Currency</LongName>
10   <LongName Identifier='listID'>ISO 4217 Alpha</LongName>
11   <Version>2001</Version>
12   <CanonicalUri>urn:un:unece:uncefact:codelist:
13  specification:54217</CanonicalUri>
14   <CanonicalVersionUri>urn:un:unece:uncefact:codelist:
15  specification:54217:2001</CanonicalVersionUri>
16   <Agency>
17   <LongName>United Nations Economic Commission for
18  Europe</LongName>
19   <Identifier>6</Identifier>
20   </Agency>
21   </Identification>
22   </ValueList>
]
6.3 ISO/IEC 19757-3 Schematron
[> 6.4][< 6.2.1][^^][^^^]
6.3.1 ISO/IEC 19757-3 Schematron
[> 6.3.2][> 6.4][> 7.][< 6.2.1][^^][^^^]
Assertion-based validation schema language
[[1] - one asserts things that must be true about an XML instance
[[2] - violations are reported when the assertion is false
][1] - one reports things that must be false about an XML instance
[[2] - violations are reported when the report is true
][1] - based on the use of XPath specification of document contexts
[[2] - recall the discussion on document contexts on [Document context representation - Section 5.1.2 Document context representation]
]]
Contrasted with grammar-based or type-based validation schema language
[[1] - grammar-based validation schema languages
[[2] - e.g. XML Document Type Definitions (DTD)
 [2] - e.g. ISO/IEC 19757-2 Regular Language for XML (RELAX-NG)
][1] - type-based validation schema language
[[2] - e.g. W3C Schema
]]
Part of the Document Schema Definition Languages (DSDL)
[[1] - custody of ISO/IEC JTC 1/SC 34/WG 1
 [1] - ISO/IEC 19757 international standard with multiple parts:
[[2] - [http://www.dsdl.org]
 [2] - Part 1 - overview
 [2] - Part 2 - RELAX-NG - regular-grammar-based validation
 [2] - Part 3 - Schematron - assertion-based validation
 [2] - Part 4 - Namespace-based Validation Dispatching Language (NVDL)
 [2] - Part 5 - Data Type Library Language (DTLL)
 [2] - Part 6 - Path-based Integrity Constraints
 [2] - Part 7 - Character Repertoire Description Language (CRDL)
 [2] - Part 8 - Document Schema Renaming Language (DSRL)
 [2] - Part 9 - Datatype- and Namespace-aware DTD
 [2] - Part 10 - Validation Management
]]
6.3.2 ISO Schematron deployment
[> 6.3.3][> 6.4][> 7.][< 6.3.1][^][^^][^^^]
Schematron schema preparation
[[1] - a master Schematron schema is created by the user to establish the Schematron environment for use of the included patterns
 [1] - fragmented Schematron schemas are assembled into a complete assertion
[[2] - <sch:include> directive points to each schema fragment
 [2] - the methodology stylesheets create a single Schematron pattern construct for inclusion for the contents of a context/value association file
 [2] - other business rule Schematron schema fragments can be included
][1] - the complete assertion schema is translated into a runtime artefact incorporating all assertion and report testing
]
Schematron schema execution
[[1] - the runtime artefact is run against the XML instances to be tested, producing the validation reports
[[2] - the nature of the report (i.e. text, XML, etc) is based on the choice of Schematron wrapper for the generated runtime artefact
]]
[Figure 6.1: CVA implementation in Schematron
Three sets of triangles feed a box labeled "XSLT Process" at the left of a large diagram. The single "XML" labeled triangle titled Code List Context Associations" and identified with a circled "3" is one of the three sets. A set of "GC" labeled triangles titled "External Code List Expressions" and identified with a circled "4" is another. A set of "XSLT" labeled triangle titled "Association Stylesheet and Imported Fragments" is the third. This third one lists the following fragments, with the first fragment in boldface font:
]
An XSLT-based reference implementation of a Schematron skeleton is freely available
[[1] - [http://www.schematron.com]
 [1] - the skeleton implements base functionality
[[2] - iso_schematron_skeleton.xsl
][1] - the skeleton is wrapped by a stylesheet that tailors the reporting style
[[2] - supplied with Message-Schematron-terminator.xsl
][1] - instances being validated are processed with the resulting output stylesheet
[[2] - validation results with a stylesheet generated using Message-Schematron-terminator.xsl:
[[3] - text-based error report to the standard error port
 [3] - testable non-zero return code on exit with error
 [3] - does not exploit the mark= facility in CVA files
]]]
[Figure 6.2: CVA implementation in Schematron and XSLT
Three sets of triangles feed a box labeled "XSLT Process" at the left of a large diagram. The single "XML" labeled triangle titled Code List Context Associations" and identified with a circled "3" is one of the three sets. A set of "GC" labeled triangles titled "External Code List Expressions" and identified with a circled "4" is another. A set of "XSLT" labeled triangle titled "Association Stylesheet and Imported Fragments" is the third. This third one lists the following fragments, with the first fragment in boldface font:
[[1] - UBL-genericode2Schematron.xsl
 [1] - {documentModel}-{externalFormat}2Schematron.xsl
 [1] - {documentModel}-Metadata.xsl
 [1] - {externalFormat}-CodeList.xsl
 [1] - Constraints2Schematron.xsl
]
The output from the XSLT process is an "SCH" labeled triangle titled "Code List Pattern". This is input to a set of "SCH" labeled triangles titled "Business Rules" and identified with a circled "5". These are input to another box labeled "XSLT Process".
The other input to this box is an "XSLT" labeled triangle titled "Schematron-ISO-assembly.xsl", and the output is an "SCH" labeled triangle titled "Validation Rules". This is input to yet another box labeled "XSLT Process".
The other input to this box is an "XSLT" labeled triangle titled "Schematron-ISO-incomplete-text.xsl".
All of the shapes to this point are above a bracket titled "Preparation". The remaining shapes are all above a bracket titled "Processing".
The output from the last process is an "XSLT" labeled triangle titled "Assertion Validation Stylesheet" and identified with a circled "2". This is input to still yet another box labeled "XSLT Process".
The remaining inputs to this last XSLT process is a set of "XML" labeled triangles titled "Document Instances Being Validated". The outputs from this last XSLT process is a set of "Report" labeled parallelograms titled "Validation Reports".
]
Other Schematron wrappers can provide other reporting features
[[1] - Schematron Validation Report Language (SVRL)
[[2] - an XML vocabulary for reporting Schematron validation results
 [2] - stylesheets available for processing validation reports
 [2] - a wrapper is already available for SVRL support
 [2] - when mark= is used in the context/value association file, the Schematron implementation of this is the flag= attribute which is accessible when using SVRL
 [2] - having the result of validation in an XML format enables one to process the results with XML-enabled tools
][1] - one can create one's own wrappers
[[2] - to meet custom requirements in a specific environment
]]
6.3.3 Schematron message construction
[> 6.4][> 7.][< 6.3.2][^][^^][^^^]
Not supplying a <Message> for a <Context> engages default messaging:
[[1] - the content in the following example is documentation, not a message
]
[Example 6-6:
01   <Context item="@currencyID" values="currency">
02   <Annotation>
03   <Description>
04   All currencies are restricted to only Canadian and US dollars.
05   </Description>
06   </Annotation>
07   </Context>
]
The default message quotes the value in error and the values= specification of the value lists involved in which the value and associated meta data is not found:
[Example 6-7:
01  Value supplied 'UYU' is unacceptable for values 
02  identified by 'currency' in the context '@currencyID':
03  /Order/cac:TaxTotal[1]/cbc:TaxAmount[1]/@currencyID
]
The pro forma structure of the message is as follows:
[Example 6-8:
01  Value supplied 'value-from-instance' is unacceptable for values 
02  identified by 'id-of-genericode-declaration' in the context
03  'document-context': instance-address-of-value
]
Note the lack of line numbers in the error message
[[1] - XML is not obliged to have line breaks and indents
 [1] - line numbers do not help when there are no line breaks in XML
 [1] - the XPath address is unambiguous
 [1] - some XML-based tools accept an XPath address as a lookup function
]
Using Schematron's <sch:value-of> one can craft a custom message:
[[1] - the <Message> element defines the content replacing the default message
]
[Example 6-9:
01    <Context item="cbc:CountrySubentityCode"
02   scope="cac:SellerSupplierParty"
03   values="states">
04   <Annotation>
05   <Description>
06   The seller can only be in the US.
07   </Description>
08   </Annotation>
09   <Message>Invalid state '<sch:value-of select="."/>' for seller
10  "<sch:value-of select="ancestor::cac:SellerSupplierParty/
11  cac:Party/cac:PartyName/cbc:Name"/>"</Message>
12   </Context>
]
The specified message is used for the report, suffixed with the XPath expression:
[Example 6-10:
01  Invalid state 'ON' for seller "Elliot's Electronics": 
02  /Order/cac:SellerSupplierParty[1]/cac:Party[1]/cac:Address[1]/
03  cbc:CountrySubentityCode[1]
]
The inclusion of the path at the end of the message is an available feature for new wrappers
[[1] - the skeleton adds support for this to the validating stylesheet as an available mode for processing nodes
 [1] - the following has been proposed to be included in the skeleton for use by a wrapper stylesheet to engage the feature
]
[Example 6-11:
01   <axsl:apply-templates select="." mode="schematron-get-full-path-3"/>
]
The above is only important when writing your own Schematron wrappers
[[1] - when using the Schematron implementation included with this methodology, there is no need to consider any changes in this regard
]
6.4 Engaging value validation using Schematron
[> 7.][< 6.3.3][^^][^^^]
6.4.1 Engaging value validation using Schematron
[> 6.4.2][> 7.][< 6.3.3][^^][^^^]
Crane-UBL-genericode2Schematron.xsl translates context/value associations for UBL into a Schematron pattern
[[1] - a pattern collects a group of rules
[[2] - each rule constrains the value of a particular information item
][1] - the pattern is given a name using the name= attribute in the context/value association file
]
Consider the example order-constraints.cva shown earlier:
[Example 6-12:
01  <ValueListConstraints 
02   xmlns="urn:oasis:names:tc:ubl:schema:Value-List-Constraints-0.8"
03   xmlns:cbc="urn:oasis:...:CommonBasicComponents-2"
04   xmlns:cac="urn:oasis:...:CommonAggregateComponents-2"
05   xmlns:sch="http://purl.oclc.org/dsdl/schematron"
06   id="urn:x-illustration"
07   name="code-list-rules">
08   ...
09  </ValueListConstraints>
]
This creates a Schematron pattern in order-constraints.sch as follows:
[Example 6-13:
01  <pattern xmlns="http://purl.oclc.org/dsdl/schematron" 
02   id="code-list-rules">
03  <!--
04  ...
05  <ns prefix="cbc" uri="urn:oasis:...:CommonBasicComponents-2"/>
06  <ns prefix="cac" uri="urn:oasis:...:CommonAggregateComponents-2"/>
07  -->
08   <rule context="@currencyID">
09   ...
10   </rule>
11  </pattern>
]
Note the embedded <ns> elements found in the comments
[[1] - these lines have no effect in the pattern because they are positioned inside of the comment
 [1] - these declarations are needed in the including master Schematron schema to satisfy the namespace requirements of the XPath addresses in the included patterns
 [1] - the prefixes are significant and should manually be harmonized across all included patterns for a single including master Schematron schema
]
Recall [Figure 6.2]
All Schematron patterns must be assembled into a single Schematron schema
[[1] - an including master Schematron schema points to all included patterns and other fragments
 [1] - the typical use is a single unnamed phase such that all patterns are engaged
 [1] - alternatively, the schema can describe multiple phases and selectively point to patterns in each phase
[[2] - invocation of the validation stylesheet can then choose the utilized phase
]]
Consider the example codes-only-constraints.sch shown earlier:
[Example 6-14:
01  <schema xmlns="http://purl.oclc.org/dsdl/schematron">
02   <title>Code list value assertions</title>
03   <ns prefix="cbc" uri="urn:oasis:...:CommonBasicComponents-2"/>
04   <ns prefix="cac" uri="urn:oasis:...:CommonAggregateComponents-2"/>
05   <include href="order-constraints.sch"/>
06  </schema>
]
iso_schematron_assembly.xsl is used to interpret <sch:include>
[[1] - this produces order-codes-only.sch in the example
]
[Example 6-15:
01  <schema xmlns="http://purl.oclc.org/dsdl/schematron">
02   <title>Code list value assertions</title>
03   <ns prefix="cbc" uri="urn:oasis:...:CommonBasicComponents-2"/>
04   <ns prefix="cac" uri="urn:oasis:...:CommonAggregateComponents-2"/>
05   <pattern id="code-list-rules">
06   ...
07   <rule context="@currencyID">
08   ...
09   </rule>
10   </pattern>
11  </schema>
]
Recall [Figure 6.2]
Business rules can be expressed in other patterns or in the including schema
[[1] - all of the patterns have equal weight
 [1] - the patterns can be grouped in phases
 [1] - matches specified in later patterns have higher priority than those in earlier patterns
]
Consider the example total-constraints.sch shown earlier:
[Example 6-16:
01  <schema xmlns="http://purl.oclc.org/dsdl/schematron"
02   defaultPhase="only-phase">
03   <title>Business rules for maximum total value</title>
04   <ns prefix="cbc"
05   uri="urn:oasis:...:CommonBasicComponents-2"/>
06   <ns prefix="cac"
07   uri="urn:oasis:...:CommonAggregateComponents-2"/>
08   <phase id="only-phase">
09   <active pattern="code-list-rules"/>
10   <active pattern="total-limit"/>
11   </phase>
12   <include href="total-limit-constraint.sch"/>
13   <include href="order-constraints.sch"/>
14  </schema>
]
The total-limit-constraints.sch pattern has business rules
[Example 6-17:
01  <pattern xmlns="http://purl.oclc.org/dsdl/schematron" 
02   id="total-limit">
03   <rule context="cbc:ToBePaidAmount">
04   <assert test=". &amp;lt; 10000">Total amount '<value-of select="."/>'
05  cannot be $10,000 or more</assert>
06   </rule>
07  </pattern>
]
iso_schematron_assembly.xsl is used to interpret <sch:include>
[[1] - this produces order-codes-total.sch in the example
]
An assembled Schematron schema is transformed into the runtime validation stylesheet
[[1] - Message-Schematron-terminator.xsl is the supplied transformation stylesheet
 [1] - the output of the transformation is the validation stylesheet acting on business document instances
 [1] - other wrappers for iso_schematron_skeleton.xsl are available from the Schematron web site
]
The order-codes-only.xsl is created for the example without business rules
[[1] - from order-codes-only.sch
[[2] - created from codes-only-constraints.sch that includes order-constraints.sch
][1] - checks only the constraints expressed in the context/value association file
]
The order-codes-total.xsl is created for the example with the business rule
[[1] - from order-codes-total.sch
[[2] - created from total-constraints.sch that includes both order-constraints.sch and total-limit-constraints.sch
][1] - checks the constraints expressed in the context/value association file and in the business rule
]
Recall the overview diagram in [Figure 5.8]
6.4.2 CVA hierarchy using Schematron
[> 7.][< 6.4.1][^][^^][^^^]
Each translated CVA file creates a Schematron pattern
[[1] - all included CVA files are incorporated into the one Schematron pattern
 [1] - the including association has priority over any included association
 [1] - for any given document context, only a single association will be tested
[[2] - the first context in document order that matches
]]
All included Schematron patterns are run in parallel
[[1] - actual order is irrelevant to validation, though the order of the error messages is impacted
 [1] - for all patterns, all document contexts will be tested, with only the highest priority association in each pattern for that context defining the test
]
[Figure 6.3: Parallel and priority processing of Schematron and CVA files
The diagram shows a master Schematron schema using sch:include to pull in two Schematron patterns, each created from one CVA file. The first CVA file uses cva:Include to include another CVA file. The second CVA file uses cva:Include twice to include two other CVA files.
The Schematron pattern directives are processed in parallel, such that all directives are processed in some arbitrary order.
The CVA associations are prioritized in reverse CVA included order, with the including CVA associations having the highest priority.
]
Deciding on the hierarchy depends on the desire for parallel or prioritized matching of document contexts
[[1] - use cva:Include for prioritized matching
[[2] - the first match in document order for each tree of CVA files is tested
][1] - use sch:include for parallel matching
[[2] - highest priority match for each included Schematron schema is tested
]]
Consider the situation where there are UBL, community and trading partner controlled vocabularies
[[1] - each group defines a CVA file for their controlled vocabularies
 [1] - use sch:include to run all tests simultaneously
 [1] - use cva:Include to run only the highest priority test
[[2] - e.g. the trading partner CVA file would include the UBL CVA file and then the community CVA file if the prioritized order of matching is that the trading partner definitions have highest priority, followed by community definitions for the next priority, followed by the UBL definitions for the lowest priority
]]


This is an accessible version of Crane's commercial training material. The content has been specifically designed to assist screen reader software in viewing the entire textual content. Figures are replaced with text narratives.

Navigation hints are in square brackets:
[Tx.x] and [Fx.x] are textual representations of the applicability icons;
[digit] indicates list depth for nested lists;
[link [URL]] indicates the URL of a hyperlink if different than link;
[EXAMPLE] indicates an example listing of code;
[FIGURE] indicates the presence of a figure replaced by its description;
[>] jumps forward;
[<] jumps backward;
[^] jumps to start of the section;
[^^] jumps to the start of the chapter;
[^^^] jumps to the table of contents.
Suggestions for improvement are welcome: [info@CraneSoftwrights.com]
Book sales: [http://www.CraneSoftwrights.com/links/trn-acc.htm]
Information: [http://www.CraneSoftwrights.com/links/info-acc.htm]
This content is protected by copyright and, as there are no means to protect this accessible version from plagiarism, please do not make any commercial edition available to others.

+//ISBN 1-894049::CSL::Presentation::UBL//DOCUMENT Practical Code List Implementation 2009-02-09 22:30UTC//EN
Practical Code List Implementation
First Edition - 2009-02-09
ISBN 978-1-894049-22-1
Copyright © Crane Softwrights Ltd.