 |
OASIS Content Assembly Mechanism Specification V1.1
OASIS Committee
Specification Draft
02 November 2006
Artifact Identifier:
cam-specification.pdf.committee.2006-11-02
Location:
Current: docs.oasis-open.org/cam/1.1/latest
This Version: docs.oasis-open.org/cam/1.1/011
Previous Version: docs.oasis-open.org/cam/ 1.0/
Artifact Type:
Technical Committee:
OASIS Content Assembly Mechanism TC
Chair(s):
David RR Webber
Editor(s):
Martin Roberts
David RR Webber
OASIS Conceptual Model topic area:
e-Commerce, XML Processing, web services
Related work:
This specification replaces or supercedes:
This specification is related to:
Abstract:
The Content Assembly Mechanism (CAM) provides an open XML based system for using business rules to define, validate and compose specific business documents from generalized schema elements and structures.
A CAM rule set and document assembly template defines the specific business context, content requirement, and transactional function of a document. A CAM template must be capable of consistently reproducing documents that can successfully carry out the specific transactional function that they were designed for. CAM also provides the foundation for creating industry libraries and dictionaries of schema elements and business document structures to support business process needs.
The core role of the OASIS CAM specifications is therefore to provide a generic standalone content assembly mechanism that extends beyond the basic structural definition features in XML and schema to provide a comprehensive system with which to define dynamic e-business interoperability.
Status:
This document was last revised or approved by the CAM TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at www.oasis-open.org/committees/cam.
Notices
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2005. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Rights, Patents, Licenses and Royalties
CAM TC Specifications (includes documents, schemas and examples) are free of any Intellectual Property Rights, Patents, Licenses or Royalties. The Public is free to download and implement the specifications without impediment. Please read OASIS Copyright Notice above.
Table of contents
Figures and Tables 5
1. Introduction 6
2. Pre-requisites 7
3. Content Assembly Mechanism Technical Specification 8
3.1. Overview 11
3.2. Header declarations 13
3.2.1 Parameters 13
3.2.2 Pseudo Variables 13
3.2.3 Properties 14
3.2.4 Imports 14
3.3. Assembly Structures 15
3.4. Business Use Context Rules 18
3.4.1 XPath syntax functions 26
3.4.2 Handling CDATA content with XPath 27
3.4.3 CAM content mask syntax 28
3.5. Predicate Format Options 37
3.6. In-line use of predicates and references 40
3.7. Use of namespace declarations 43
3.8. Extending CAM Processors 45
3.8.1 as:Extension 45
3.8.2 Preprocessor Extensions 46
3.8.3 Postprocessor Extensions 46
3.8.4 as:include 46
3.9. Future Feature Extensions 47
4. References 48
5. Related Normative References 48
6. Terms and Definitions 49
7. Symbols and Abbreviations 50
8. Disclaimer 52
A Addendum 53
A1.1 CAM schema (W3C XSD syntax) 53
A1.2 CAM Processor Notes (Non-Normative) 53
A1.3 Processing Modes and Sequencing 54
B Addendum 55
B1.1 CAM extension mechanism example 55
Appendix A. Acknowledgements 56
Appendix B. Revision History 57
Figures and Tables
Figure 1 - The implementation model for a CAM processor
Figure 2 - Deploying CAM Technology – Context Driven Assembly
Figure 3 - Deploying CAM technology – Context Driven Validation
Figure 4 – Deploying CAM technology – Defining Content Rules and Structures
Figure 5 - High-level parent elements of CAM (in simple XML syntax)
Figure 6 - Structure for entire CAM syntax at a glance
Figure 7 – Example of Structure and format for AssemblyStructure
Figure 8 - Substitution and fixed parameters values, with a well-formed XML structure
Figure 9 - The Assertion predicates for BusinessUseContext
Figure 10 – Syntax example for BusinessUseContext
Figure 11 - Matrix of predicates for BusinessUseContext declarations
Figure 12 - XPath Comparator functions.
Figure 13 - Matrix of in-line statement commands and predicate commands
Figure 14 - Use of in-line commands with a well-formed XML structure
Figure 15 - An example of namespace declarations for CAM templates
1. Introduction
The core role of CAM remains the same - defining, composing and validating XML content. The version 1.1 of the CAM specification seeks to simplify the original work and more clearly delimit between core normative features and extended non-normative sections and items. Also V1.1 builds from lessons learned over the past two years in developing actual CAM templates. The new approach aligns closely with common industry practice in marshalling and unmarshalling XML content, the XML DOM and allows the use of common XML tools, including rule engines, alongside the CAM toolset. Consequently the CAM toolset now provides a powerful set of typical XML scripted functional components that by default are needed when exchanging XML business transactions.
The XML scripting is designed to be obvious, human readable and declarative. This means that the task of providing rule-driven control mechanisms can become open and re-usable across an ebusiness community of practice, not just for localized internal point solutions. This is especially important in today’s web service environments to support the concept of loose-coupling of service interfaces and their associated transaction interchanges. We have also taken into account the W3C and OMG work on rules.
The objective in releasing v1.1 is to provide a foundation specification that is simple, clear and easy to implement today. Whereas the new approach now allows integration with specialized tools that link into backend database systems and/or handles specialized structure formats, specialized error handling mechanisms or provide engines for complex rule based logic. In addition support for external context mechanisms are provided to align with business process needs, such as the OASIS ebBP/BPSS.
This approach is designed to separate the common sharable needs from the in-house local specializations in a coherent systematic way. This allows implementers to isolate their own point development and still align with common community practice and core business information handling structures and rules.
Future extensions to the specification may then build out and provide additional normative tools as extended areas are better formalized and common industry practice establishes itself. An example of the need to develop further normalized specification parts include registry interfacing and marshalling and unmarshalling to and from SQL content repositories. Today these are provided by specialized tools and CAM provides a formal extension mechanism and application programming interface (API) for these non-normative needs.
Figure 1 - The implementation model for a CAM processor
Referencing Figure 1 - the top-most XML-aware functions are normative components required of a CAM processor to support the core XML-scripting functionality. The lower components are optional tools supported by the pluggable interface that CAM v1.1 provides. Implementors can use local specialized tools as determined by their specific application environment. It is envisioned this implementation model can be developed using a variety of modern programming languages and the pluggable interface is supported by tools such as the Apache Foundation Maven technology. This flexibility allows for support of W3C Rule Interchange Format (RIF) and OMG Production Rule Representation (PRR) as applicable.
2. Pre-requisites
These specifications make use of W3C technologies, including the XML V1.0, XML namespaces, W3C Schema V1.0 (XSD) with W3C Schema data types V1.0, and XPath 1.0 recommendations. It should be noted that only a subset of the XPath technology, specifically the locator sections of the XPath specification are utilized. Explicit details of XPath syntax are provided in the body of this specification. A schema definition is provided for the assembly mechanism structure. Knowledge of these technologies is required to interpret the XML sections of this document.
3. Content Assembly Mechanism Technical Specification
This section describes the implementation specifications for CAM. As noted above there are three roles to CAM – defining, composing and validating content. Figure 1 shows how implementers can integrate CAM technology into their existing content generation systems, while Figure 2 shows CAM in a content validation role, and then Figure 3 shows defining content rules.
Figure 2 - Deploying CAM Technology – Context Driven Assembly
In reference to Figure 2 - Deploying CAM Technology – Context Driven Assembly, item 1 is the subject of this section, describing the syntax and mechanisms. Item 2 is a process engine designed to implement the CAM logic as an executable software component, and similarly item 3 is the application XML marshalling and unmarshalling component that links the e-business software to the physical business application software and produces the resultant transaction payload for the business process needs.
Input to the conceptual model section can come from UML and similar modelling tools to define the core components and relevant re-usable business information components themselves, or can come from existing industry domain dictionaries.
The specification now continues with the detailing the physical realization in XML of the CAM template mechanism itself using a fully-featured eBusiness deployment environment example.
The Figure 2 shows how CAM can be integrated as a content validation service within a transactional exchange system using partner profiles, context and actions to drive transaction validation.
Figure 3 - Deploying CAM technology – Context Driven Validation
Referencing the Figure 3 - Deploying CAM technology – Context Driven Validation, the business partner (#1) sends business transactions (#2) to the partners messaging server (#3). The messaging envelope (#4) contains the sender action and the data handler (#5) checks that against the partner profiles on record in the Registry (#6). The sender action from the envelope also determines via the CPA (Collaboration Partner Agreement) the CAM template associated with that business process step. The data handler (#5) then invokes the CAM validation services (#7) and passes the references to: the inbound transaction on the receive queue, the sender context and the CAM template. The CAM validation services (#7) then verifies the content and returns either the precise error details found or a valid transaction status back to the data handler for action. Using this configuration allows CAM to act as a context driven validation service that is configurable via the partner CPA, the Sender Action from the message envelope received, and the CAM templates defined for the business process.
Then Figure 4 below provides a lower level of detail into the XML script mechanisms required and the business analysis steps that lead to the definition of these contents.
Figure 4 – Deploying CAM technology – Defining Content Rules and Structures
Referencing Figure 4 above the business analyst examines the business transaction schema layouts (#1), the sample production transmissions, and references the industry vocabulary dictionary. Using the CAM template the actual transaction structure required (#2) is defined. This may optionally contain additional context rules (#3) that direct CAM processing based on variables and values (the header section can contain global context declarations). Then noun references may also be created (#4) that cross-reference between the structure elements (#2) and the registry dictionary (#5) and the approved industry noun definitions. Optionally local application validation rules (#6) may also be added that test specific local requirements and also optional (#7) is the application mappings (such as database table columns). Used in this role the CAM template captures the information exchange details in an XML template that can then be shared and referenced between partners and agreed to as the business information requirements.
The tools from both Figure 3 and Figure 4 can also be deployed interactively via a web browser interface to allow partners to pre-test, and / or, self-certify prior to production message exchanges being sent. This can provide online interactive tools where sample XML transactions can be tested by upload to a CAM validation tool that applies the selected template and reports online any errors detected.
The CAM itself consists of four logical sections and the CAM template is expressed in XML syntax. This is shown in figure 5 as high-level XML structure parent elements[1].
Figure 5 - High-level parent elements of CAM (in simple XML syntax)
<CAM CAMlevel="1" version="1.1">
<Header>
<AssemblyStructure/>
<BusinessUseContext/>
<Extension/> <!—Optional, repeatable -->
</CAM>
The structure sections provide the core of the publically agreed interchange definition between exchange partners - Assembly Structure(s), and Business Use Context Rules. Then the internal pre- or post processing can be referenced as local include extensions as needed for specializations.
The optional extensions and includes are envisioned to support specialized non-normative handling that in the prior CAM specification functionality included items such as Content References (with optional associated data validation), extended Data Validations including rule agents and marshalling/unmarshalling content via External Mappings. These process needs are now retained as future potential normative items that are still evolving and described in a non-normative companion document to the main V1.1 specification as Appendix B.
Figure 6 - Structure for entire CAM syntax at a glance[2] next shows the complete v1.1 specification hierarchy for CAM at a glance.
The CAM header it should be noted has built-in support for compatibility levels within the specification to both aid in implementation of the CAM tools, and also to ensure interoperability across versions.
This is controlled via the CAMlevel attribute of the CAM root element. More details on the CAM implementation levels and features are provided in advanced options section later.
Figure 6 - Structure for entire CAM syntax at a glance
Each of the parent items is now described in detail in the following sub-sections, while the formal schema definition for CAM is provided at the OASIS web site in machine readable Schema format XSD syntax. While the documented schema provides a useful structural overview, implementers should always check for the very latest version on-line at the docs.oasis-open.org/cam area to ensure conformance and compliance to the latest explicit programmatic details.
The next sections describe each parent element in the CAM in sequence, their role and their implementation details.
3.2. Header declarations
The purpose of the Header section is to declare properties and parameters for the CAM process to reference. There are three sub-sections: parameters, properties and imports. Within the main header there are elements that allow documenting of the template description, owner, assigning of a version number and providing a date/time stamp. These are used for informational purposes only and maybe used by external processes to verify and identify that a particular CAM template instance is the one required to be used.
3.2.1 Parameters
This section allows parameters to be declared that can then be used in context specific conditions and tests within the CAM template itself. These can either be substitution values, or can be referencing external parameter values that are required to be passed into this particular CAM template by an external process. CAM uses the $name syntax to denote external parameter references where required in the CAM template statements. External parameters can be passed using the CAM context mechanism (see later section on Advanced Features support).
3.2.2 Pseudo Variables
This item is non-normative, level 2.
When processing documents it is often expedient to have access to the system time. This would allow checks against that time to be made and therefore validation to check for example that delivery dates are in the future. To do this CAM defines the following pseudo variables.
- $date – this gives today’s date in the format YYYY-MM-DD
- $time – this gives the time at the start of processing the incoming file in the format HH:MI:SS
- $dateTime – this is a combination of the previous variables in the format YYYY-MM-DDTHH:MI:SS
These variables should be set by the processor at the start of processing for each incoming document.
In addition there is a need for date math functions to be provided to allow checks against the current time and date and also between date fields. The following is considered a minimal set that may be provided.
These functions compare a field with the date or time of the validation:
- dateAfterNow(xpath,dateMask)
- timeAfterNow(xpath,timeMask)
- dateBeforeNow(xpath,dateMask)
- timeBeforeNow(xpath,timeMask)
The following functions allow either a positive or negative integer, which represents either days or hours to be added to Now:
- dateAfterDays(xpath,dateMask,numofdays)
- timeAfterHours(xpath,dateMask,numofhours)
- dateBeforeDays(xpath,dateMask,numofdays)
- timeBeforeHours(xpath,dateMask,numofhours)
The following functions allow comparison between two fields:
- after(xpath,mask,xpath,mask)
- before(xpath,mask,xpath,mask)
3.2.3 Properties
This item is non-normative, level 2.
These allow creation of shorthand macros that can be referenced from anywhere in the remainder of the CAM template using the ${macroname} reference method. This is designed to provide an easy way to maintain references to external static URL values particularly. It can also be used to define shorthand for commonly repeated blocks of syntax mark-up within the CAM template itself, such as a name and address layout, or a particular XPath expression.
3.2.4 Imports
This item is non-normative, level 2.
The import reference allows the CAM processor to pre-load any reference links to external files containing syntax to be included into the CAM template. It also allows the external path of that include file to be maintained in just one place in the template; making easier maintenance if this is re-located. In addition this then allows an <include> statement within the CAM template to reference the import declaration and select a particular sub-tree of content syntax to insert at that given point (using an XPath statement to point to the fragment within the overall import file). This also allows the included content to be done by using just one large file, instead of multiple small files.
The include statements would have the format:
<as:include>$importname/xpath</as:include>
An example with an import declared as ‘common_rules’ would be as follows:
<as:include>$common_rules//as:BusinessUseContext/as:Rules/as:default</as:include>
This example will load any default rules from the ‘common_rules’ CAM Template into the current template.
The next section begins describing the main
processing associated with the CAM template.
3.3. Assembly Structures
The purpose of the AssemblyStructure section is to capture the required content structure or structures that are needed for the particular business process step (i.e. one business process step may have more or more structures it may contextually need to create). This section is designed to be extremely flexible in allowing the definition of such structures. The current V1.x series of the specification uses simple well-formed XML throughout to illustrate the usage. Later releases of the CAM specification consideration will be made to allow any fixed structured markup as potentially being utilized as an assembly structure, such as DTD, Schema, EDI[3], or other (typically they will be used as substitution structures for each other). It is the responsibility of the implementer to ensure that all parties to an e-business transaction interchange can process such content formats where they are applicable to them (of course such parties can simply ignore content structures that they will never be called upon to process).
Notice also that typically a single business process with multiple steps would be expected to have multiple CAM templates, one for each business process step. While it is also possible to provide a single CAM template with multiple structures for a business process with multiple steps, this will likely not work unless the business transaction for each step is essentially the same (since the content reference section and context rules section would have to reference potentially extremely different structures).
Using single CAM templates per step and transaction structure also greatly enhances re-use of CAM templates across business processes that use the same structure content, but different context.
The formal structure rules for AssemblyStructure are expressed by the syntax in 0 below. The Figure 7 – Example of Structure and format for AssemblyStructure here shows a simple example for an AssemblyStructure using a single structure for content.
Figure 7 – Example of Structure and format for AssemblyStructure
<Header>
<Description>Example 4.2.1 using structures</Description>
<Version>0.05</Version>
</Header>
<AssemblyStructure>
<Structure taxonomy=”XML”> //XML is the only allowed value for Version 1.1
<!-- the physical structure of the required content goes here, and can be a schema instance, or simply well-formed XML detail, see example below in Figure 8 -->
</Structure >
</AssemblyStructure>
In the basic usage, there will be just a single structure defined in the AssemblyStructure / Structure section. However, in the more advanced use, multiple substitution structures may be provided and use of include directives. These can also be included from external sources, with nesting of assemblies; see the section below on Advanced Features for details.
To provide the direct means to express content values within the structure syntax the following two methods apply. A variable substitution value for an element or attribute is indicated by text that must start and end with a ‘%’sign, for example ‘%Description%’; or simply %% where no indicative content is preferred..Any other value is assumed to be a fixed content value. Figure 8 - Substitution and fixed parameters values, with a well-formed XML structure shows examples of this technique.
Figure 8 - Substitution and fixed parameters values, with a well-formed XML structure
<Header>
<Description>Example 4.2.2 Well-formed XML structure</Description>
<Version>1.0</Version>
<as:Parameters>
<as:Parameter name="DeliveryCountry"
values="USA|Mexico|Canada|Europe "
use="Global"
default="USA"/>
</as:Parameters>
</Header>
<AssemblyStructure>
<Structure taxonomy=”XML”>
<Items CatalogueRef=”2006”> //Fixed Value
<SoccerGear>
<Item>
<RefCode>%000_00_0000%</RefCode> // Value subject to rules
<Description>%any text line%</Description>
<Style>WorldCupSoccer</Style>
<UnitPrice>%amount%</UnitPrice>
</Item>
<QuantityOrdered>%integer%</QuantityOrdered>
<SupplierID>%%</SupplierID>
<DistributorID>%%</DistributorID>
<OrderDelivery>Normal</OrderDelivery>
<DeliveryAddress>
<USA> // details of address here
</USA>
<Mexico> // details of address here
</Mexico>
<Canada> // details of address here
</Canada>
<Europe> // details of address here
</Europe>
</DeliveryAddress>
</SoccerGear>
</Items>
</Structure>
</AssemblyStructure>
Referring to Figure 8 - Substitution and fixed parameters values, with a well-formed XML structure, the “2006”, “WorldCupSoccer” and “Normal” are fixed values that will always appear in the payload transaction at the completion of the CAM processing of the content.
In addition to the XML markup, within the AssemblyStructure itself may optionally be included in-line syntax statements. The CAM system provides the BusinessUseContext section primarily to input context rules (see section below), however, these rules may be optionally included as in-line syntax in the AssemblyStructure. However, all rules where present in the BusinessUseContext section take precedence over such in-line syntax rules.
The next section details examples of in-line context rules.
3.4. Business Use Context Rules
Once the assembly structure(s) have been defined, then the next step is to define the context rules that apply to that content. The technique used is to identify a part of the structure by pointing to it using an XPath locator reference, and then also applying an assertion using one of the structure predicates provided for that purpose (an optional comparison evaluation expression can also be used with the XPath locator reference where applicable).
Note: By default CAM assumes that any XML structure item, element or attribute, is mandatory unless a rule is added in the BusinessUseContext section or an inline rule is placed in the structure.
Note: By default CAM will not enforce order of elements within an XML structure unless a rule is added in the BusinessUseContext section or an inline rule is placed in the structure (same behaviour as with XML 1.0 attributes ordering being undetermined). This feature makes CAM templates more flexible, particularly for complex structures, and prevents erroneous error flagging.
There are two sections to these business context rules, default rules normally apply, and conditional rules that only apply if a particular rule block evaluates to true. The business rules then take the form of structure assertion predicates that define the cardinality (aka occurrence usage rules) of the structure members and content definitions. Figure 9 - The Assertion predicates for BusinessUseContext shows the structure assertion predicates.
Figure 9 - The Assertion predicates for BusinessUseContext
|
excludeAttribute() |
useAttribute() |
|
excludeElement() |
useChoice() |
|
excludeTree() |
useElement() |
|
makeOptional() |
useTree() |
|
makeMandatory() |
useAttributeByID() |
|
makeRepeatable() |
useChoiceByID() |
|
setChoice() |
useElementByID() |
|
setId() |
useTreeByID() |
|
setLength() |
startBlock() |
|
setLimit() |
endBlock() |
|
setValue() |
checkCondition() |
|
setDateMask() |
makeRecursive() |
|
setStringMask() |
setUID() |
|
setNumberMask() |
restrictValues() |
|
datatype() or setDataType() |
restrictValuesByUID() |
|
setRequired() |
orderChildren() |
Each predicate provides the ability to control the cardinality of elements[4] within the structure, or whole pieces of the structure hierarchy (children within parent).
An example
of such context rules use is provided below, and also each predicate and its’
behaviour is described in the matrix in figure 4.3.3 below. Also predicates
can be used in combination to provide a resultant behaviour together, an
example is using makeRepeatable() and makeOptional() together on a structure
member.
Note that the BusinessUseContext section controls use of the structure, while
if it is required to enforce explicit validation of content, then there is also
the non-normative DataValidations section that provides the means to check
explicitly an element to enforce content rules as required. See below for
details on this section. This validation section is also further described in
the advanced use section since it can contain extended features.
Predicates that affect the definition are applied using the following precedence rules. The lower numbered rules are applied first and can be overridden by the high numbered rules.
1. AssemblyStructure Inline predicates.
2. BusinessUseContext default rules and predicates.
3. BusinessUseContext conditional rules and predicates.
Referring to the structure in the example shown in Figure 8 - Substitution and fixed parameters values, with a well-formed XML structure, Figure 10 – Syntax example for BusinessUseContext provides examples of context based structural predicate assertions. Notice that such context rules can be default ones that apply to all context uses of the structure, while other context rules can be grouped and constrained by a XPath locator rule expression. There are three styles of such XPath expressions:
1. XPath expression refers to structure members directly and controls their use
2. XPath expression refers to structure member and contains condition of its value
3. XPath expression refers to a variable that has been created from the Parameter or the Properties section in the Header.
Such XPath expressions will match all the structural elements that they can refer to, so if a unique element is always required, implementers must ensure to provide the full XPath identity so that only a single unique match occurs. An example is a reference to “//ZIPCode” which will match any occurrence, whereas “/BillingAddress/ZIPCode” will only match that item.
Figure 10 – Syntax example for BusinessUseContext
<BusinessUseContext>
<Rules>
<default>
<context> <!-- default structure constraints -->
<constraint action="makeRepeatable(//SoccerGear)" />
<!-- type 1 Xpath-->
<constraint action="makeMandatory(//SoccerGear/Items/*)" />
<constraint action="makeOptional(//Description)" />
<constraint action="makeMandatory(//Items@CatalogueRef)" />
<constraint action="makeOptional(//DistributorID)" />
<constraint action="makeOptional(//SoccerGear/DeliveryAddress)" />
</context>
</default>
<context condition="//SoccerGear/SupplierID = 'SuperMaxSoccer'">
<!-- type 2 Xpath-->
<constraint action="makeMandatory(//SoccerGear/DeliveryAddress)"/>
</context>
<context condition="$DeliveryCountry = 'USA'">
<!-- type 3 Xpath using parameter DeliveryCountry-->
<constraint action="useTree(//SoccerGear/DeliveryAddress/USA)"/>
</context>
</Rules>
</BusinessUseContext>
Referring to the XPath expressions in Figure 10 – Syntax example for BusinessUseContext, examples of all three types of expression are given to show how the XPath expressions are determined and used. For external control values the special leading $ indicator followed by the variable name denotes a substitution value from a context reference variable that is declared in the CAM template header.
Referring to Figure 11 - Matrix of predicates for BusinessUseContext declarations) below, the following applies:
|
//elementpath |
XPath expression resolving to an element(s) in the structure. This parameter is not required when predicate is used in-line, since then it is implicit. |
|
//memberpath |
XPath expression resolving to either an element(s) or an attribute(s) in the structure |
|
//treepath |
XPath expression resolving to parent element with children in the structure |
|
//StructureID |
reference to an in-line ID assignment within the structure, or ID value assigned using setID() predicate. |
|
//elementpath@ attributename |
XPath expression resolving to an attribute or attributes in the structure |
|
//attributepath |
This can be used interchangeably with //elementpath when //memberpath is an allowed parameter of a predicate. Either a single XPath expression resolving to an attribute in the structure, or a collection of XPath expressions referencing more than one attribute for the given element of the form //elementpath@[attributename1, attributename2, attributename3,…], or //elementpath@[*] to reference all attributes for that element. |
|
IDvalue |
String name used to identify structure member |
|
UIDreference |
Valid UID and optional associated registry and taxonomy that points to an entry in a Registry that provides contextual metadata content such as a [valuelist] or other information |
|
value, valuelist, count, mask |
String representing parameter. When lists are required then group with paired brackets [ a, b, c, …], and when group of groups use nested brackets [[a, b, d, f],[d, e, g, m]] Note: groups are required for collections of attributes in in-line predicate assertions. |
Figure 11 - Matrix of predicates for BusinessUseContext declarations
|
Predicate |
Parameter(s) |
Description |
|
excludeAttribute() |
//elementpath@attributename |
Conditionally exclude attribute from structure |
|
excludeElement() |
//elementpath |
Conditionally exclude element from structure |
|
excludeTree() |
treepath |
Conditionally exclude a whole tree from structure |
|
makeOptional() |