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 Content Assembly Mechanism TC on the above date. The level of approval is also listed above. Check the "Latest Version" or "Latest Approved Version" location noted above for possible later revisions of this document.

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 http://www.oasis-open.org/committees/cam/

The CAM TC work is operating on an open license approach charter with unencumbered content, see the Technical Committee web page at http://www.oasis-open.org/committees/cam/charter.php

For information relating to disclosure of patents pertaining to the CAM TC work, and if any such contributing member statements exist, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/cam/ipr.php)

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/cam/

Notices

Copyright © OASIS® 1993-2007. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, 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 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

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' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on 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 implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", "Content Assembly Mechanism (CAM)" are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction 6

1.1 Terminology 7

1.2 Normative References 7

1.3 Non-Normative References 7

1.4 Terms and Definitions 7

1.5 Symbols and Abbreviations 8

2 Pre-requisites 11

3 Content Assembly Mechanism Technical Specification 12

3.1 Overview 15

3.2 Header declarations 17

3.2.1 Parameters 17

3.2.2 Pseudo Variables 17

3.2.3 Properties 17

3.2.4 Imports 18

3.3 Assembly Structures 18

3.4 Business Use Context Rules 21

3.4.1 XPath syntax functions 29

3.4.2 Handling CDATA content with XPath 30

3.4.3 CAM content mask syntax 30

3.5 Predicate Format Options 39

3.6 In-line use of predicates and references 42

3.7 Advanced Features 46

3.8 Use of namespace declarations 46

3.9 Extending CAM Processors 47

3.9.1 as:Extension 47

3.9.2 Preprocessor Extensions 48

3.9.3 Postprocessor Extensions 48

3.9.4 as:include 48

3.9.5 Template Location defaulting 48

3.9.6 Selection of Assembly Structure 48

3.10 Future Feature Extensions 49

A. Addendum 51

A1.1 CAM schema (W3C XSD syntax) 51

A1.2 CAM Processor Notes (Non-Normative) 51

A1.3 Processing Modes and Sequencing 52

B. Addendum 53

B1.1 CAM extension mechanism example 53

C. Acknowledgements 54

D. Non-Normative Text 55

E. Revision History 56

Figures and Tables

Figure 1 - The implementation model for a CAM processor 6

Figure 2 - Deploying CAM Technology - Context Driven Assembly. 12

Figure 3 - Deploying CAM technology - Context Driven Validation. 13

Figure 4 - Deploying CAM technology - Defining Content Rules and Structures. 14

Figure 5 - High-level parent elements of CAM (in simple XML syntax) 15

Figure 6 - Structure for entire CAM syntax at a glance. 16

Figure 7 - Example of Structure and format for AssemblyStructure. 19

Figure 8 - Substitution and fixed parameters values, with a well-formed XML structure. 19

Figure 9 - The Assertion predicates for BusinessUseContext 21

Figure 10 - Syntax example for BusinessUseContext 23

Figure 11 - Matrix of predicates for BusinessUseContext declarations. 25

Figure 12 - XPath Comparator functions. 29

Figure 13 - Matrix of in-line statement commands and predicate commands. 42

Figure 14 - Use of in-line commands with a well-formed XML structure. 45

Figure 15 - An example of namespace declarations for CAM templates. 46

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. Implementers 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.

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 (see abbreviation references below).

All text is normative unless otherwise labelled.

1.2 Normative References

- XML Path Language (XPath) specifications document, version 1.0, W3C Recommendation 16 November 1999, http://www.w3.org/TR/xpath/

- Extensible Markup Language (XML) specifications document, version 1.1, W3C Candidate Recommendation, 15 October 2002, http://www.w3.org/TR/xml11/

- XML Schema Definitions (XSD) - [XSD1] XML Schema Part 1: Structures, W3C Recommendation 2 May 2001 http://www.w3.org/TR/xmlschema-1/

http://www.oasis-open.org/committees/download.php/6248/xsd1.html

[XSD2] XML Schema Part 2: Datatypes, W3C Recommendation 2 May 2001

http://www.w3.org/TR/xmlschema-2/

http://www.oasis-open.org/committees/download.php/6247/xsd2.html

- XNL: Specifications & Description Document, OASIS CIQ TC, http://www.oasis-open.org/committees/ciq

- XAL: Specifications & Description Document, OASIS CIQ TC, http://www.oasis-open.org/committees/ciq

- ISO 16642 - Representing data categories http://www.loria.fr/projets/TMF/

- CEFACT - Core components specifications - http://webster.disa.org/cefact-groups/tmg/

1.3 Non-Normative References

- Jaxen reference site - http://jaxen.org/

- UN - eDocs resource site - http://www.unece.org/etrades/unedocs/

- UN - Codelists reference site for eDocs - http://www.unece.org/etrades/unedocs/codelist.htm

1.4 Terms and Definitions

Assembly model

A tree-structured model that can be implemented as a document schema.

Class diagram

A graphical notation used by [UML] to describe the static structure of a system, including object classes and their attributes and associations.

Component model

A representation of normalized data components describing a potential network of associations and roles between object classes.

Context

The circumstance or events that form the environment within which something exists or takes place.

Dependency diagram

A refinement of a class diagram that emphasizes the dependent associations between object classes.

Document

A set of information components that are interchanged as part of a business transaction; for example, in placing an order.

Functional dependency

A means of aggregating components based on whether the values of a set of properties change when another set of properties changes, that is, whether the former is dependent on the latter.

Normalization

A formal technique for identifying and defining functional dependencies.

Spreadsheet model

A representation of an assembly model in tabular form.

XSD schema

An XML document definition conforming to the W3C XML Schema language [XSD1][XSD2].

The terms Core Component (CC), Basic Core Component (BCC), Aggregate Core Component (ACC), Association Core Component (ASCC), Business Information Entity (BIE), Basic Business Information Entity (BBIE), and Aggregate Business Information Entity (ABIE) if used in this specification refer to the meanings given in [CCTS].

The terms Object Class, Property Term, Representation Term, and Qualifier are used in this specification with the meanings given in [ISO11179].

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].

1.5 Symbols and Abbreviations

ABIE

Aggregate Business Information Entity

ACC

Aggregate Core Component

ASBIE

Association Business Information Entity

ASCC

Association Core Component

ASN.1

ITU-T X.680-X.683: Abstract Syntax Notation One; ITU-T X.690-X.693: ASN.1 encoding rules

http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-X.693-0207w.zip

http://www.oasis-open.org/committees/download.php/6320/X.680-X.693-0207w.zip

BBIE

Basic Business Information Entity

BCC

Basic Core Component

BIE

Business Information Entity

Core Component

CCTS

UN/CEFACT ebXML Core Components Technical Specification 2.01

http://www.untmg.org/downloads/General/approved/CEFACT-CCTS-Version-2pt01.zip

http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip

EAN

European Article Numbering Association

EDI

Electronic Data Interchange

ISO

International Organization for Standardization

ISO11179

ISO/IEC 11179-1:1999 Information technology - Specification and standardization of data elements - Part 1: Framework for the specification and standardization of data elements

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c002349_ISO_IEC_11179-1_1999(E).zip

http://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999%28E%29.pdf

JSDF

Java Simple Date Format library

NDR

UBL Naming and Design Rules (see Appendix B.4)

RFC2119

Key words for use in RFCs to Indicate Requirement Levels

http://www.faqs.org/rfcs/rfc2119.html

http://www.oasis-open.org/committees/download.php/6244/rfc2119.txt.pdf

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

UML

Unified Modeling Language [UML] Version 1.5 (formal/03-03-01)

http://www.omg.org/docs/formal/03-03-01.pdf

http://www.oasis-open.org/committees/download.php/6240/03-03-01.zip

UN/CEFACT

United Nations Centre for Trade Facilitation and Electronic Business

XML

Extensible Markup Language [XML] 1.0 (Second Edition),W3C Recommendation 6 October 2000

http://www.w3.org/TR/2000/REC-xml-20001006

http://www.oasis-open.org/committees/download.php/6241/REC-xml-20001006.pdf

XSD

W3C XML Schema Language [XSD1] [XSD2]

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.

3.1 Overview

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>

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

<Description>Example 4.2.1 using structures</Description>

</Header>

<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 Figur