Embedding Schematron in XML Schema Documents
Version 1.0alpha4
March 16, 2016
NIEM Technical Architecture Committee (NTAC)
Authors

Webb Roberts, Georgia Tech Research Institute (<webb.roberts@gtri.gatech.edu>), Lead Author

Abstract

The Embedding Schematron in XML Schema Documents specification, version 1.0alpha4, provides methods that simplify the use of Schematron with XML Schema documents.

Document Status

This document is an early draft product of the NIEM Technical Architecture Committee (NTAC). This version of this document is not normative. The release version of this document will be normative when approved by the NTAC.

Table of Contents
1. Introduction

The Embedding Schematron in XML Schema Documents specification, version 1.0alpha4, provides methods that simplify the use of Schematron with XML Schema documents. The following sections describe the objectives and methods of this specficiation.

1.1. Background

[Schematron] does not specify any methods or provide recommendations for the use of Schematron XML Schema within XML Schema. It provides Annex F, Use of Schematron as a Vocabulary, which identifies Schematron elements that are fit to be used within other vocabularies.

Prior to this specfication, Schematron rules have been embedded in XML Schema documents by putting sch:ns, sch:title, sch:phase, and sch:pattern elements within xs:appinfo in XML Schema documents. This is supported by the XSLT ExtractSchFromXSD-2.xsl, which is part of the iso-schematron-xslt2.zip distribution provided at http://www.schematron.com/implementation.html. That XSLT processes embedded Schematron into a separate Schematron file with an xslt2 query binding.

1.2. Methodology

This specification defines a methodology for adding Schematron rules to an XML Schema document, and specifies how those rules are to be interpreted. Goals include:

Schemas that conform to this specification include Schematron rules on XML Schema components within xs:appinfo. Those rules are extracted to Schematron files. Those Schematron files may target an XSLT 1 processor, XSLT 2 basic XSLT processor, or XSLT 2 schema-aware XSLT processor. Those Schematron files can also be made portable, to run with over those components regardless of how they are used within a schema. For example, a rule on a complex type can be applied to any element of that complex type.

This specification establishes processing requirements by establishing characteristics of an implied Schematron document, which is a Schematron document that results from correct processing of a schema document with embedded Schematron. Rather than specifying details of exactly how to process a schema document with embedded Schematron, it provides high-level requirements. For example, a sch:assert on an element declaration is required to correspond to a sch:pattern with an sch:rule with a context that applies to any instance of the specified element, and to any element in the substitution group of that element. How this is accomplished might differ between a Schematron document targeted to an XSLT 1 processor and one targeted to an XSLT 2 schema-aware XSLT processor.

1.3. Objectives

This section outlines some issues with embedding Schematron in XML Schema documents, and how this specification resolves them.

1.3.1. Clarify processing requirements

This specification refines the query binding construct defined by [Schematron], to make it clarify what kind of XSLT processor is needed to process Schematron rules within an XML Schema document.

[Schematron] Section 6.4, Query Language Binding, provides a query language binding, which identifies the language used by sch:assert test attributes, sch:value-of select attributes, and other queries on data. It provides a list of recommended names for query languages, however:

  • It does not specify what is meant by any given query language name.
  • It does not specify what is required of a processor that processes Schematron with any given query language.
  • It does not distinguish between the capability of xslt and xpath, or between xpath2 and xslt2.
  • It does not distinguish between XSLT 2.0’s basic XSLT processor and schema-aware XSLT processor.

These shortcomings mean that it is difficult for a Schematron processor to know if it will be able to execute a set of Schematron rules with a given XSLT processor.

This specification provides an attribute, six:queryBinding, which tells which XSLT processors that are capable of executing the Schematron rules within the schema document. The attribute has a list of values:

The example in Figure 1-1, Example of six:queryBinding specifying XSLT 2, below, indicates that embedded Schematron rules would run on any XSLT 2 processor: a basic XSLT processor or an XSLT 2 schema-aware XSLT processor.

Figure 1-1: Example of six:queryBinding specifying XSLT 2
<xs:schema
    six:queryBinding="xslt2"
    xmlns:six="http://release.niem.gov/niem/sch-in-xsd/1.0/">
  ...
</xs:schema>

The example in Figure 1-2, Example of six:queryBinding specifying XSLT 1 and XSLT 2, below, indicates that embedded Schematron rules would run on an XSLT 1 processor, an XSLT 2 basic XSLT processor or an XSLT 2 schema-aware XSLT processor.

Figure 1-2: Example of six:queryBinding specifying XSLT 1 and XSLT 2
<xs:schema
    six:queryBinding="xslt1 xslt2"
    xmlns:six="http://release.niem.gov/niem/sch-in-xsd/1.0/">
  ...
</xs:schema>

The example in Figure 1-3, Example of six:queryBinding specifying a schema-aware XSLT processor, below, indicates that embedded Schematron rules would run on an XSLT 2 schema-aware XSLT processor.

Figure 1-3: Example of six:queryBinding specifying a schema-aware XSLT processor
<xs:schema
    six:queryBinding="xslt2-sa"
    xmlns:six="http://release.niem.gov/niem/sch-in-xsd/1.0/">
  ...
</xs:schema>

This method of defining processor requirements for Schematron rules has advantages:

  • It narrows the options down to fielded XSLT processors: XSLT 1 and XSLT 2 processors.
  • It distinguishes between XSLT 2.0’s basic XSLT processor and its schema-aware XSLT processor.
  • It supports Schematron rules that can be executed with both an XSLT 1 and an XSLT 2 processor.
1.3.2. Unify XML Schema document namespace declarations with Schematron’s

This specification simplifies namespace declarations used in embedded Schematron statements, because it ensures the XML prefixes defined and used in XML Schema documents are also used for Schematron rules.

Schematron defines its own mechanism (sch:ns) for binding namespace prefixes to namespace URIs. The naive approach, of scraping embedded Schematron into a separate Schematron file, would mean that most namespace declarations must be defined twice: once how XML and XML Schema do it, and again for Schematron using sch:ns.

The example in Figure 1-4, Example of sch:ns, below, shows an XML prefix declaration for prefix sch, and a Schematron namespace declaration for namespace xs. Only Schematron namespace declarations may be used in Schematron sch:rule context attributes, sch:assert test attributes, and other XPath expressions within the Schematron rules.

Figure 1-4: Example of sch:ns
<sch:schema
    xmlns:sch="http://purl.oclc.org/dsdl/schematron">
  ...
  <sch:ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/>
  ...
</sch:schema>

This introduces problems:

  • Namespaces for Schematron must be maintained separately from namespaces for XML Schema, requiring additional work.
  • Namespace bindings in Schematron and XML Schema could differ, misleading users and developers, who expect a prefix (such as nc) to mean only one thing.

This specification ensures that the standard XML method of specifying namespace prefixes propagates to embedded Schematron rules. It does this by requiring that namespace declarations appear only on the schema document’s document element. This ensures that the document does not define namespace prefixes elsewhere in the document, which can’t be represented in a Schematron document.

Figure 1-5: Example of XML namespaces
<xs:schema
   xmlns:sch="http://purl.oclc.org/dsdl/schematron"
   xmlns:xs="http://www.w3.org/2001/XMLSchema">
  ...
</xs:schema>
1.3.3. Provide for bare asserts, reports, and let

This specification provides for bare sch:let, sch:assert, and sch:report as application information on some schema components, which greatly simplifies the use of Schematron in XML Schema documents.

The conventional use of Schematron in XML Schema documents consists of putting sch:pattern elements in xs:appinfo annotations. Suppose this is in the nc namespace:

Figure 1-6: Example of sch:pattern in an element declaration
<xs:element name="PersonFullName" type="nc:PersonNameTextType">
  <xs:annotation>
    <xs:appinfo>
      <sch:pattern>
        <sch:rule context="nc:PersonName">
          <sch:assert test="count(nc:PersonGivenName) = 1"
            >Element must have one nc:PersonGivenName.</sch:assert>
        </sch:rule>
      </sch:pattern>
    </xs:appinfo>
  </xs:annotation>                
</xs:element>

This example has issues:

  • Although the rule is attached to element nc:PersonFullName, it describes a chracteristic of element nc:PersonName. The context of the rule is not what one would expect, and removing this component from a subset would remove a rule unrelated to the component. It is best to make a rule apply to the component on which it is attached.
  • Since the context is explicit (instead of coming from a schema component definition), changing the name of the component would cause the rule to not apply, instead of having the rule apply to the renamed component.
  • Since the rule’s context is nc:PersonName, it would not apply to elements derived from that element via substitutionGroup. It is best to stay true to the Liskov Substitution Principel, and ensure that rules for a component also hold for derived components.

This specification allows the use of sch:pattern as shown above, but it also allows a schema component to have sch:assert, sch:report, and sch:let without sch:pattern and sch:rule. For example:

Figure 1-7: Example of sch:pattern in xs:appinfo
<xs:element name="PersonName" type="nc:PersonNameType">
  <xs:annotation>
    <xs:appinfo>
      <sch:assert test="count(nc:PersonGivenName) = 1"
        >Element must have one nc:PersonGivenName.</sch:assert>
    </xs:appinfo>
  </xs:annotation>                
</xs:element>

Advantages include:

  • Rule contexts always match the component on which rules appear.
  • Rule contexts don’t have to be separately maintained.
  • Rule contexts can work with an XSLT 1.0 processor, an XSLT 2.0 basic XSLT processor, or an XSLT 2.0 schema-aware XSLT processor.
  • Rule contexts can apply to derived components, including elements derived through substitution, and elements of derived types.
  • Rule contexts can apply to elements and attributes of specified types, and to components using derived types.
2. Terminology

This document relies on terminology defined by other specifications and standards, as well as terminology specific to this specification. This section introduces many terms, and directs the reader to the external source definition of a term when appropriate. The following sections reflect the different sources and topics of this terminology:

2.1. RFC 2119 terminology

Within normative content (rules and definitions), 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].

2.2. XML

This specification uses terminology from [XML] to describe parts of XML documents. Terms used include:

2.3. XML Namespaces

This document uses XML namespaces as defined by [XMLNamespaces] and [XMLNamespacesErrata]

2.4. XML Information Set

[XMLInfoSet] defines terms and properties that describe the values of and relationships between parts of an XML document. This document uses this terminology to refer to content of XML documents. Terminology used includes:

2.5. XML Schema

The term XML Schema definition language is defined by [XMLSchema1], Abstract, which states:

XML Schema: Structures specifies the XML Schema definition language, which offers facilities for describing the structure and constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in XML 1.0 and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type definitions (DTDs).

The term schema document is defined by [XMLSchema1] Section 3.1.2, XML Representations of Components, which states:

A document in this form (i.e. a <schema> element information item) is a schema document.

The term XML Schema is defined by [XMLSchema1] Section 2.2, XML Schema Abstract Data Model, which states:

An XML Schema is a set of schema components.

The term schema component is defined by [XMLSchema1] Section 2.2, XML Schema Abstract Data Model, which states:

Schema component is the generic term for the building blocks that comprise the abstract data model of the schema.

2.6. XSLT 2.0

The term basic XSLT processor is defined by [XSLT2] Section 21.1, Basic XSLT Processor, which states:

A basic XSLT processor is an XSLT processor that implements all the mandatory requirements of this specification with the exception of certain explicitly-identified constructs related to schema processing.

The term schema-aware XSLT processor is defined by [XSLT2] Section 21.2, Schema-Aware XSLT Processor, which states:

A schema-aware XSLT processor is an XSLT processor that implements all the mandatory requirements of this specification, including those features that a basic XSLT processor signals as an error.

2.7. Schematron

The Schematron specification [Schematron] coins and uses the term Query Language Binding to refer to the framework that defines the syntax of queries (e.g., test and select) and the types of the results of queries made by a Schematron file. Relevant sections include Section 6.4, Query Language Binding, and Annex C, Default Query Language Binding.

2.8. NIEM Conformance Target Attribute Specification

This specification uses terms from [CTAS], including:

2.9. NIEM Naming and Design Rules

The term application information (of a schema component) is defined by [NIEM NDR] Section 10.9, Machine-readable annotations, describing the contents of xs:appinfo annotations on the element that defines a schema component.

3. Namespaces used in this document

Namespace prefixes used in this document:

Figure 3-1: Schematron namespaces
<sch:ns prefix="ct" uri="http://release.niem.gov/niem/conformanceTargets/3.0/"/>
<sch:ns prefix="sch" uri="http://purl.oclc.org/dsdl/schematron"/>
<sch:ns prefix="six" uri="http://release.niem.gov/niem/sch-in-xsd/1.0/"/>
<sch:ns prefix="xsl" uri="http://www.w3.org/1999/XSL/Transform"/>
4. Terms and Definitions
[Definition: schema document with embedded Schematron]

Conformance target identifier: http://reference.niem.gov/niem/specification/sch-in-xsd/1.0/#XSDWithSchematron.

This conformance target uses the conformance target code XSD

[Definition: implied Schematron document]

An implied Schematron document of an schema document with embedded Schematron is a Schematron document that is produced by conformant processing of a schema document with embedded Schematron.

5. Rules
5.1. XML Schema rules
Rule 5-1. Document is an XML Schema document
[Rule 5-1] (XSD) (Constraint)

The document MUST be a schema document.

Rule 5-2. Document has xs:schema document element
[Rule 5-2] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="/">
    <sch:assert test="/xs:schema"
                >The document MUST have document element xs:schema.</sch:assert>
  </sch:rule>
</sch:pattern>
Rule 5-3. XML Schema elements do not appear as content of annotations
[Rule 5-3] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="xs:*">
    <sch:assert test="empty(ancestor::xs:appinfo | ancestor::xs:documentation)"
                >An element in the XML Schema namespace MUST NOT appear as content of an XML Schema annotation.</sch:assert>
  </sch:rule>
</sch:pattern>
5.2. Conformance target rules
Rule 5-4. Document conforms to Conformance Targets Attribute Specification
[Rule 5-4] (XSD) (Constraint)

The document MUST be a conformant document, as defined by [CTAS].

Rule 5-5. Document has effective conformance target identifier
[Rule 5-5] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="/">
    <sch:assert test="some $conformance-target 
                      in tokenize(normalize-space( (//@ct:conformanceTargets)[1] ), ' ')
                      satisfies $conformance-target = 'http://reference.niem.gov/niem/specification/sch-in-xsd/1.0/#XSDWithSchematron'"
        >The document MUST have an effective conformance target identifier "http://reference.niem.gov/niem/specification/sch-in-xsd/1.0/#XSDWithSchematron".</sch:assert>
  </sch:rule>
</sch:pattern>
5.3. Rules on six:queryBinding
Rule 5-6. Attribute six:queryBinding owner element is xs:schema
[Rule 5-6] (XSD) (Constraint)
<sch:pattern>
   <sch:rule context="*[@six:queryBinding]">
     <sch:assert test="self::xs:schema"
         >Attribute six:queryBinding MUST have [owner element] xs:schema</sch:assert>
   </sch:rule>
</sch:pattern>
Rule 5-7. Schema element has query binding
[Rule 5-7] (XSD) (Constraint)
<sch:pattern>
   <sch:rule context="/xs:schema">
     <sch:assert test="@six:queryBinding"
         >Document element xs:schema MUST have attribute six:queryBinding</sch:assert>
   </sch:rule>
</sch:pattern>
Rule 5-8. Attribute six:queryBinding identifies query language
[Rule 5-8] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="*[@six:queryBinding]">
    <sch:assert test="every $token in tokenize(normalize-space(@six:queryBinding),' ')
                      satisfies $token = ('xslt1', 'xslt2', 'xslt2-sa')"
        >Attribute six:queryBinding must indicate query language binding.</sch:assert>
  </sch:rule>
</sch:pattern>
Rule 5-9. Attribute six:queryBinding sets processing expectations
[Rule 5-9] (XSD) (Interpretation)

The application information attribute six:queryBinding on a schema document with embedded Schematron contains a list of strings that reflect the processing requirements of Schematron rules appearing within the schema document. The attribute six:queryBinding MUST be interpreted as follows:

There is no query language binding defined by [Schematron] that indicates schema-aware processing versus basic processing. The schema-aware and basic XSLT processors are defined by [XSLT2], not by [XPath2], so there is no normative source for how to process a Schematron document with query language binding of xpath2.

The xslt2 query binding implies xslt2-sa. Including both is redundant, but harmless.

5.4. Rules on namespaces
Rule 5-10. Namespace prefixes declared only on the document element
[Rule 5-10] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="*[not(self::* is /*)]">
    <sch:let name="element" value="."/>
    <sch:let name="parent" value="$element/parent::*"/>
    <sch:let name="element-prefixes" value="in-scope-prefixes($element)"/>
    <sch:let name="parent-prefixes" value="in-scope-prefixes($parent)"/>
    <sch:assert test="every $prefix in $element-prefixes 
                      satisfies ($prefix = $parent-prefixes
                                 and namespace-uri-for-prefix($prefix, $element) 
                                     = namespace-uri-for-prefix($prefix, $parent))
                      and (every $prefix
                           in $parent-prefixes
                           satisfies $prefix = $element-prefixes)"
        >The document MUST NOT have a namespace prefix definition on any element that is not the document element.</sch:assert>
  </sch:rule>
</sch:pattern>
Rule 5-11. No use of sch:ns
[Rule 5-11] (XSD) (Constraint)

A component of a schema document with embedded Schematron MUST NOT have application information that is an element sch:ns.

All namespace declarations in the implied Schematron document are originated from the namespace declarations appearing on the document element xs:schema.

Rule 5-12. Implied Schematron document has sch:ns
[Rule 5-12] (XSD) (Interpretation)

The implied Schematron document of schema document with embedded Schematron $document MUST have a sch:ns element corresponding to each namespace declaration that occurs on the [document element] of $document.

5.5. Schematron throughout the document
Rule 5-13. Implied Schematron document contains application information from document
[Rule 5-13] (XSD) (Interpretation)

The implied Schematron document of schema document with embedded Schematron $document MUST contain, preserving document order, content corresponding to:

  • element application information of the [document element] xs:schema of $document that has the namespace corresponding to the prefixes sch and xsl,
  • element application information of any element sch:pattern within $document, and
  • other corresponding content of an implied Schematron document, as defined by this specification.

Note that the namespace prefixes sch and xsl are defined for this document in Section 2.3, XML Namespaces, above.

5.6. Occurrence of Schematron content
Rule 5-14. XSLT elements allowed only as top-level annotations
[Rule 5-14] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="xs:*/xsl:*">
    <sch:assert test="parent::xs:appinfo[parent::xs:annotation[.. is /xs:schema]]"
      >An XSLT element MUST be application information on the schema document.</sch:assert>
  </sch:rule>
</sch:pattern>
Rule 5-15. Most Schematron elements allowed only as top-level annotations
[Rule 5-15] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="xs:*/sch:*[not(self::sch:assert)
                                and not(self::sch:report)
                                and not(self::sch:let)]">
    <sch:assert test="parent::xs:appinfo[parent::xs:annotation[.. is /xs:schema]]"
      >A Schematron element other than sch:assert, sch:report, and sch:let MUST be application information on the schema document.</sch:assert>
  </sch:rule>
</sch:pattern>
Rule 5-16. Schematron assert, report, let allowed on particular components
[Rule 5-16] (XSD) (Constraint)
<sch:pattern>
  <sch:rule context="xs:*/sch:assert
                     | xs:*/sch:report 
                     | xs:*/sch:let">
    <sch:assert test="parent::xs:appinfo[parent::xs:annotation[parent::xs:*[
                        (: top-level components :)
                        ( ( self::xs:element or self::xs:attribute 
                            or self::xs:complexType or self::xs:simpleType )
                          and ( .. is /xs:schema ) )
                        (: element and attribute uses :)
                        or ( ( self::xs:element[@ref] or self::xs:attribute[@ref] )
                             and ancestor::xs:complexType[.. is /xs:schema] ) ]]]"
      >A Schematron assert, report, or let element MUST be application information on one of: a global attribute declaration, a global element declaration, a global complex type definition, a global simple type definition, a global element particle within a global complex type definition, or a global attribute use within a global complex type definition.</sch:assert>
  </sch:rule>
</sch:pattern>
Rule 5-17. Application information corresponds to a valid Schematron document
[Rule 5-17] (XSD) (Constraint)

The document MUST NOT contain any annotations from the sch or xsl namespaces that would result in an invalid implied Schematron document.

Rule 5-18. Schema component definitions have limited Schematron content
[Rule 5-18] (XSD) (Constraint)

Elements other than xs:schema MUST NOT have application information in the sch namespace other than:

  • Any element with the namespace corresponding to the prefix xs MAY have application information sch:pattern.
  • Other XML Schema component-defining elements MAY have specific application information in the namespace corresponding to the prefix sch only as explicitly allowed by other rules in this specification.
5.7. Top-level attribute declaration
Rule 5-19. Schematron application information allowed on top-level attribute declaration
[Rule 5-19] (XSD) (Constraint)

An element xs:attribute with [parent] element xs:schema MAY have have application information elements sch:let, sch:assert, and sch:report.

Rule 5-20. Application information of top-level attribute declaration entails pattern
[Rule 5-20] (XSD) (Interpretation)

The content in an implied Schematron document corresponding to occurrences of elements sch:let, sch:assert, or sch:report as application information of an element xs:attribute with [parent] element xs:schema corresponds to an occurrence of element sch:pattern with [children] containing an element sch:rule, with context that applies to any element with [attributes] containing that attribute. This sch:rule has [children] containing elements that correspond to the elements sch:let, sch:assert, or sch:report, preserving document order.

5.8. Top-level element declaration
Rule 5-21. Schematron application information allowed on top-level element declaration
[Rule 5-21] (XSD) (Constraint)

An element xs:element with [parent] element xs:schema MAY have have application information elements sch:let, sch:assert, and sch:report.

Rule 5-22. Application information of top-level element declaration entails pattern
[Rule 5-22] (XSD) (Interpretation)

The content in an implied Schematron document corresponding to occurrences of sch:let, sch:assert, or sch:report on an element xs:element with [parent] element xs:schema corresponds to an occurrence of element sch:pattern with child element sch:rule, with context that applies to any occurrence of that element, or an element in the substitution group of that element. This sch:rule has [children] containing elements corresponding to sch:let, sch:assert, and sch:report, preserving document order.

5.9. Top-level complex type definition
Rule 5-23. Schematron application information allowed on top-level complex type definition
[Rule 5-23] (XSD) (Constraint)

An element xs:complexType with [parent] element xs:schema MAY have have application information elements sch:let, sch:assert, and sch:report.

Rule 5-24. Application information of top-level complex type definition entails pattern
[Rule 5-24] (XSD) (Interpretation)

The content in an implied Schematron document corresponding to occurrences of sch:let, sch:assert, or sch:report on an element xs:complexType with [parent] element xs:schema corresponds to an occurrence of element sch:pattern with child element sch:rule, with context that applies to any occurrence of an element that is of that type, or is of a type derived from that type. This sch:rule has children of corresponding to sch:let, sch:assert, and sch:report, preserving document order.

5.10. Top-level simple type definition
Rule 5-25. Schematron application information allowed on top-level simple type definition
[Rule 5-25] (XSD) (Constraint)

An element xs:simpleType with [parent] element xs:schema MAY have have application information elements sch:let, sch:assert, and sch:report.

Rule 5-26. Application information of top-level simple type definition entails patterns
[Rule 5-26] (XSD) (Interpretation)

The content in an implied Schematron document corresponding to a set of occurrences of sch:let, sch:assert, or sch:report on an element xs:simpleType with [parent] element xs:schema corresponds to zero or more occurrence of element sch:pattern, each with [children] containing element sch:rule, with context that applies to any occurrence of an element that is of that type, or is of a type derived from that type. This sch:rule establishes a variable $six:value that has a value of the instance content that is of the simple type. This sch:rule has subsequent element children of corresponding to the sch:let, sch:assert, and sch:report from the document, preserving document order.

Simple type definitions are particularly tricky, in that Schematron processors generally do not support rule context on specific simple content; contexts on text nodes or attribute values will yield errors and warnings. For this reason, simple content values need a level of redirection; a separate Schematron sch:pattern may be established for each element of a simple type, each element with simple content of a simple type, or each attribute of a simple type. Each of these is defined as needed; multiple patterns will primarily be needed when schema-aware XSLT is not the target of the generated Schematron document.

5.11. Element use within a complex type
Rule 5-27. Schematron application information allowed on element use in a top-level complex type definition
[Rule 5-27] (XSD) (Constraint)

An element matching the XPath expression

/xs:schema/xs:complexType//xs:element[@ref]

MAY have have application information elements sch:let, sch:assert, and sch:report.

Rule 5-28. Application information of element use in top-level complex type definition entails pattern
[Rule 5-28] (XSD) (Interpretation)

Content of a schema document with embedded Schematron corresponding to the elements sch:let, sch:assert, and sch:report that are application information on an element matching the XPath expression:

/xs:schema/xs:complexType//xs:element[@ref]

has corresponds to an implied Schematron document with an occurrence of element sch:pattern with [children] containing element sch:rule with context that applies to any occurrence of the element identified by the ref attribute, or any element that may be substituted for that element, that occurs within any element that has the identified complex type, or a type derived from that complex type. This sch:rule has [children] elements corresponding to sch:let, sch:assert, and sch:report, preserving document order.

5.12. Attribute use within a complex type
Rule 5-29. Schematron application information allowed on attribute use in top-level complex type definition
[Rule 5-29] (XSD) (Constraint)

An element matching the XPath expression

/xs:schema/xs:complexType//xs:attribute[@ref]

MAY have have application information elements sch:let, sch:assert, and sch:report.

Rule 5-30. Application information of attribute use in top-level complex type definition entails pattern
[Rule 5-30] (XSD) (Interpretation)

Within a schema document with embedded Schematron, elements sch:let, sch:assert, and sch:report that are application information on an element matching the XPath expression:

/xs:schema/xs:complexType//xs:attribute[@ref]

corresponds to a implied Schematron document with an occurrence of element sch:pattern with [children] containing element sch:rule with attribute context that applies to any occurrence of an element that has the identified complex type, or a type derived from that complex type, that owns the attribute identified by the ref attribute. This sch:rule has [children] elements corresponding to elements sch:let, sch:assert, and sch:report, preserving document order.

6. XPath functions usable within XSLT 2.0 Schematron expressions
6.1. Function six:resolve

The function six:resolve is designed to resolve NIEM reference elements to their targets, to simplify XPath expressions.

Function interface:

six:resolve($elements as element()*) as element()*

The function six:resolve yields:

If $elements is an empty-sequence(), then yield '()', an empty sequence.

Otherwise, for each $element in sequence $elements, yield:

If $element has attribute structures:ref $ref, yield:

If there is an element $target with attribute structures:id with value $ref, then yield $target

Otherwise, yield '()', an empty sequence. It is RECOMMENDED that implementations indicate an error if this case occurs.

Otherwise, yield $element.

Appendix A. References

[CTAS]: Roberts, Webb. NIEM Conformance Targets Attribute Specification, Version 3.0. NIEM Technical Architecture Committee, July 31, 2014. http://reference.niem.gov/niem/specification/conformance-targets-attribute/3.0/NIEM-CTAS-3.0-2014-07-31.html.

[NIEM NDR]: Roberts, Webb. National Information Exchange Model Naming and Design Rules, Version 3.0. NIEM Technical Architecture Committee, July 31, 2014. http://reference.niem.gov/niem/specification/naming-and-design-rules/3.0/NIEM-NDR-3.0-2014-07-31.html.

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

[Schematron]: ISO/IEC STANDARD 19757-3: Information Technology — Document Schema Definition Languages (DSDL) Part 3: Rule-Based Validation — Schematron. ISO/IEC, June 1, 2006. http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip.

[XML]: Bray, Tim, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau. Extensible Markup Language (XML) 1.0 (Fifth Edition). The World Wide Web Consortium (W3C), November 26, 2008. http://www.w3.org/TR/2008/REC-xml-20081126/.

[XMLInfoSet]: Cowan, John, and Richard Tobin. XML Information Set (Second Edition), February 4, 2004. http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.

[XMLNamespaces]: Bray, T., Hollander, D., Layman, A., Tobin, R., & Thompson, H. S. (2009, December 8). Namespaces in XML 1.0 (Third Edition). W3C. Retrieved from http://www.w3.org/TR/2009/REC-xml-names-20091208/

[XMLNamespacesErrata]: Namespaces in XML Errata, 6 December 2002. Available from http://www.w3.org/XML/xml-names-19990114-errata.

[XMLSchema1]: XML Schema Part 1: Structures Second Edition, W3C Recommendation, 28 October 2004. Available from http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.

[XPath2]: Berglund, Anders, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon. XML Path Language (XPath) 2.0 (Second Edition). W3C, January 3, 2011. http://www.w3.org/TR/2010/REC-xpath20-20101214/

[XSLT2]: Kay, Michael. XSL Transformations (XSLT) Version 2.0. W3C, January 23, 2007. http://www.w3.org/TR/2007/REC-xslt20-20070123/.

Appendix B. Schema document for Schematron in XSD vocabulary (informative)

This schema document is provided to support the user, but is not considered normative. The syntax of six:queryBinding is provided via Rule 5-8, Attribute six:queryBinding identifies query language (XSD), above.

<?xml version="1.0" encoding="us-ascii"?>
<schema targetNamespace="http://release.niem.gov/niem/sch-in-xsd/1.0/"
        xmlns="http://www.w3.org/2001/XMLSchema">
  <annotation>
    <documentation>This is a schema for a vocabulary for use by XML Schema
      documents that conform to "Embedding Schematron in XML Schema Documents",
      version 1.0.</documentation>
  </annotation>
  
  <attribute name="queryBinding">
    <simpleType>
      <list>
        <simpleType>
          <restriction base="string">
            <enumeration value="xslt1"/>
            <enumeration value="xslt2"/>
            <enumeration value="xslt2-sa"/>
          </restriction>
        </simpleType>
      </list>
    </simpleType>
  </attribute>
  
</schema>
Appendix C. Index of Rules
Appendix D. Index of Definitions