1.1.1.  Semantics

The ModSpec Core Standard defines requirements for conformance to the ModSpec, but testing for that conformance may depend on how the various forms and parts of a conformant standard are viewed. The ModSpec Part 3 Standard specifies how those views are to be defined as XML.

As suggested in Clause Requirement 8 of the ModSpec Core, the structure of the normative clauses in a standard should parallel the structure of the conformance test classes in that standard. The structure of the normative clauses in a well written standard will follow the structure of its model. This means that all three are parallel.

1.1.2.  ModSpec document structure

Version 1.1 of the ModSpec is split into a Core standard and multiple Parts. These are:

7.1.1.  Requirements class: The XML schema extension to the core

The XML schema extension requirements class covers any standard which has as one of its purposes the introduction of a new XML schema. Such a standard would normally define the schema, all of its components, and its intended uses.

Table 1

Requirements Class — XML extension to the core
/req/core/data-representation
Target	ModSpec Conformant XML Model
Dependency	OGC ModSpec Version 1.1 [25-003r1]
REQ001	/req/part3/xml/conformance-with-core
REQ002	/req/part3/xml/w3c-xml
REQ003	/req/part3/xml/single-xml-space
REQ004	/req/part3/xml/all-components-uri
REQ005	/req/part3/xml/direct-dependency
REQ006	/req/part3/xml/no-element-modification

First, by the requirements above, the extension relationship of this conformance test class to the core must be made explicit.

Table 2

REQ001

/req/part3/xml/conformance-with-core An implementation passing the XML conformance test class SHALL first pass the ModSpec Core conformance test class

Table 3

REQ002

/req/part3/xml/w3c-xml An implementation passing the XML schema conformance test class SHALL first pass the W3C Recommendation for XML schema.

Each XML schema file (usually *.xsd) carries a target namespace specification, recorded in the targetNamespace attribute of the <schema> element in the XML representation. In its implementation, this namespace is represented by a globally unique identifier, a URI. All schema components defined with that URI as its namespace designation are part of the same module in XML schema.

The XML Schema specification lists those resolution strategies for namespace and schema that a schema-aware process may use. They work in a predictable fashion independent of the choice of strategy if and only if the schemas are in a one to one correspondence to their namespace. A schema may be dependent on another schema and may contain “import” directives that load all such schemas whenever it is loaded.

When a process loads a schema as defined by its namespace URI identity, it must always get a linkage to all components in that namespace. If not, then at sometime in the future, the process will fail when it finds a reference to such a component that it missed. To prevent this sort of failure, when a schema-aware process first encounters a namespace URI it must always be associated to a schema location (a file) that contains or includes all schema components having the URI as their namespace. This is referred to as the “all-components schema document”.

In defining a XML schema (either completely, or partially in a standard) the fundamental component or module of XML schema is always the namespace and its associated schema, which is designated by a URI.

Table 4

REQ003

/req/part3/xml/single-xml-space If a standard conformant to the XML schema conformance class defines a set of data schemas, all components (e.g., elements, attributes, types …​) associated with a single conformance test class SHALL be scoped to a single XML namespace.

Table 5

REQ004

/req/part3/xml/all-components-uri The all-components schema document for an XML Schema SHALL indicate the URI of the associated conformance test class in the schema/annotation/appinfo element.

The mechanism for dependencies may either be by importation or by inclusion of schema components.

Example

This is a choice of design, and at the level of the ModSpec, the trade-off factors cannot be prejudged because the details of such cost-benefit trade-offs are not constant. Either of the above approaches may be used.

Table 6

REQ005	/req/part3/xml/direct dependency If a standard conformant to the XML schema conformance class defines a direct dependency from one requirement class to another, then a standardization target of the corresponding conformance test class SHALL import a schema that has passed the associated conformance test class (dependency) or shall itself pass the associated conformance test class.
NOTE:  This implies that the value of the schemaLocation on the <import> element will refer to the all-components schema document.

Table 7

PER001

/per/part3/xml/schema-assembly An all-components schema document MAY be assembled by inclusion of documents that describe subsets of the components associated with the conformance test class.

This allows schema designers to do some modularization within a namespace for convenience, notwithstanding the requirement for an all-components schema document.

Table 8

REQ006

/req/part3/xml/no-element-modification The all-components schema document for an XML Schema SHALL indicate the URI of the associated conformance test class in the schema/annotation/appinfo element.

Table 9

PER002

/per/part3/xml/add-constraints Requirements may add constraints.

This allows extensions to restrict the following.

In summary, effective modularization is enabled by following the pattern of one conformance class per XML namespace; i.e., the set of components in an XML namespace should be referred to as a whole. Subsetting of components in a single XML namespace for conformance purposes is not permitted.

7.1.2.  Optional Requirements class: Schematron extension

Schematron (ISO/IEC 19757-3:2006) provides a notation with which many constraints on XML documents can be expressed. As such, Schematron is a rule-based validation language for making assertions about the presence or absence of patterns in XML trees. It is a structural schema language expressed in XML using a small number of elements and XPath languages.

This requirements class covers any standard that uses Schematron to create patterns or constraints for an XML Schema.

Table 10

Requirements Class — XML Schematron extension to the core
/req/core/data-representation
Target	ModSpec Conformant XML Model
Dependency	OGC ModSpec Version 1.1 (need proper title and document number)
REQ007	/req/part3/xml/schematron-xml-schema
REQ008	/req/part3/xml/sch-pattern-constraints
REQ010	/req/part3/xml/fpi-attribute-is-uri
REQ011	/req/part3/xml/see-attribute-is-identifier
REQ012	/req/part3/xml/one-fpi-attribute-per-schema

First the schema must be defined within the bounds of the XML schema requirements class.

Table 11

REQ007

/req/part3/xml/schematron-xml-schema A standard passing the Schematron conformance test class SHALL also define or reference an XML schema that shall pass the XML schema conformance class from this standard.

Within a Schematron schema, the “pattern” and “schema” elements may be used in a way that corresponds with conformance tests and a conformance test class as follows:

Table 12

REQ008	/req/part3/xml/sch-pattern-constraints
A	Each sch:assert element SHALL implement constraints described in no more than one requirement.
B	Each requirement SHALL be implemented by no more than one sch:pattern.
NOTE:  Requirement 9 was removed in the ModSpec version 1.1 as this requirement is present in the latest Schematron RelaxNG schema.

The Formal Public Identifier (fpi) attribute names the Schematron schema. In the ModSpec Part 2 extension, this identifier is a URI.

Table 13

REQ010

/req/part3/xml/fpi-attribute-is-uri The value of the sch:schema/@fpi attribute SHALL be a URI that identifies this implementation.

The @see attribute in Schematron provides a hypertext link to documentation or related material for each pattern, rule, or assertion. This allows the Schematron schema to be integrated into a wider information system. In the ModSpec Part 2 extension, this attribute is the identifier for a requirements class.

Table 14

REQ011

/req/part3/xml/see-attribute-is-identifier The value of the sch:schema/@see attribute SHALL be the identifier for the requirements class that contains the requirement(s) implemented by the schema

Table 15

REQ012

/req/part3/xml/one-fpi-attribute-per-schema The value of the sch:schema/@fpi attribute SHALL be used on only one Schematron schema.

7.1.3.  Optional Requirements class: XML meta-schema extension to the ModSpec Core.

This requirements class covers any standard which has as one of its purposes the introduction of a new type of XML schema. Such a standard would normally define the characteristics of such schema, how its components are created and its intended uses.

First, by the requirements above, the extension relationship of this conformance test class to the core must be made explicit.

Table 16

REQ013

/req/part3/xml/first-pass-core-conformance A standard passing the XML meta-schema conformance test class SHALL first pass the ModSpec Core conformance test class.

Since the target is defining requirements for XML schemas, it will require that the ModSpec be used.

Table 17

REQ014

/req/part3/xml/pass-XML-schema-conformance-class A standard passing the XML meta-schema conformance test class SHALL require that its targets (XML schema) pass the XML schema conformance class.