OGC Model for Writing Modular Specifications

OGC Request for Comments on Candidate Specification Model Standard

March 12, 2009. Wayland, MA, USA. [With Excerpts from the Specification]

The membership of the Open Geospatial Consortium, Inc. (OGC) is requesting comments from the public on the candidate OGC Document, The OGC Specification Model: Writing Modular Specifications.

This document, prepared by the Policy 1.0 Standards Working Group (SWG), derives from the collective experience of members in developing and implementing OGC standards, geospatial applications, platforms and services. It provides a logical model and template for candidate standards to assure their internal logic and conformance to accepted software development procedures and the OGC's policy and rules regarding the structure of standards and the types of information that they must provide.

The policy guidance will make implementation of OGC standards and the construction of compliance tests easier through enforced traceability of requirements to implementation tests, and it will make modularization of both standards and implementations more explicit and consistent across dependent standards and implementations.

This standard has been referred to as the "core and extension model" due to the insistence on a modular structure throughout all parts of a standard and its implementation. Eventually, all OGC standards will be transitioned to the new structure. This will help standardize the manner in which OGC standards are written and implemented, making implementations easier to test for compliance, thus improving interoperability between and swap-ability between implementations.

The 30-day public comment period begins March 12, 2009 and closes on April 11, 2009. Comments will be reviewed and processed by the OGC Membership. The intent is to edit the Specification Model candidate standard and move the document to be an approved OGC standard. The Specification Model Request for Comment document can be downloaded from the OGC web site:

http://www.opengeospatial.org/standards/requests/55

The OGC is an international consortium of more than 370 companies, government agencies, research organizations, and universities participating in a consensus process to develop publicly available geospatial standards. OpenGIS Standards support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT. OGC Standards empower technology developers to make geospatial information and services accessible and useful with any application that needs to be geospatially enabled. Visit the OGC website at http://www.opengeospatial.org/.

Contact

Sam Bacharach
Executive Director, Outreach and Community Adoption
Open Geospatial Consortium, Inc
35 Main Street, Suite 5, Wayland, MA 01778 USA
Tel: +1-703-352-3938
Email: sbacharach@opengeospatial.org

Excerpts from the Specification

The Specification Model — Modular Specifications. Open Geospatial Consortium Inc. Publication date: 2009-03-11. SWG Internal Version: 23. SWG Internal Version Date: 2008-12-03. Reference number of this OGC project document: OGC 08-131r2. OGC Version: 1.0.1. Category: OGC Policy Standard. Editor: OGC Policy Standards Working Group (SWG). Status: SWG RFC Submission. 63 pages. Normative Annex A: Abstract Conformance Test Suite. Normative Annex B: Changes required in the OGC Standards; transition plan for incorporation into the OGC procedures. Informative Annex C: Definitions. Annex D: Bibliography. Download URIs: PDF, (Word .doc).

Authors: Arliss Whiteside (BAE Systems C3I Systems), Paul Scarponcini (Bentley Systems, Inc), Simon Cox (CSIRO), David Danko (ESRI), Clemens Portele (Interactive Instruments GmbH), John R. Herring (Oracle USA), Andreas Matheus (University of the Bundeswehr — ITS), Richard Pearsall (US National Geospatial Intelligence Agency — NGA), Barry Reff (US Department of Homeland Security — DHS).

Introduction. From the specification 'Introduction':

[..] "A standard's usefulness and hence worth can be measured by: (1) The ease with which it can be implemented. (2) The number of times it has been implemented. (3) The number of times those implementations are used. (4) The ease with which those implementations interact. (5) The number of times it has been extended through inclusion in other useful standards. Some of these are affected by the choice of topic, but all are affected by the internal logical structure of the standard. This standard specifies generic rules for this internal structure conducive to being a true RUE ('really useful engine')..."

"A standard is a partial solution to a design problem which limits solutions to enhance interoperability and harmony between disparate solution implementations. Design issues and requirements are transformed into statements about the solution design, and are then presented in the standard as requirements of the solution, usually as requirement statements targeting the solution.

Thus, a standard presents requirements targeting implementations of solutions of the original problem, which must be satisfied the tests of the conformance suite. These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. These give the standard a modular structure, each requirements class represented by a conformance class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the conformance clause..."

Scope. From the specification 'Scope':

Scope: This standard specifies some desirable characteristics of a standards specification that will encourage implementations by minimizing difficulty, mimicking implementation structure and optimizing usability and interoperability. Clause 6.1 contains the model of a standard upon which this standard is described. Annex C contains informal and non-normative definitions ordered for ease of understanding. These two sections can be read first to aid in the understanding of the rest of the document...

Conformance. From the specification 'Conformance' section:

There are five conformance classes for this standard:

Specification documents in general (the core) — see Clause 6 and Annex A.1 2.

Specifications using UML to state requirements, extending the core — see Clause 7.2.2 and Annex A.2 3.

Specifications using XML schema to state requirements, extending the core — see Clause 7.2.3 and Annex A.3.

Specifications using Schematron to state requirements, extending XML schema — see Clause 7.2.4 and Annex A.4 5.

Specifications defining requirement for a new category of XML schemas, extending the core, whose target XML schemas must be conformant with the XML schema conformance class above — see Clause 7.2.5 and Annex A.5.

Foreword. From the specification 'Foreword':

"This standard began as discussions in the OGC Architecture Board (OAB) about general principals of application development taken from the OAB members' collective experience. Since this standard is a summary of collective experience, no one should claim intellectual property rights to its contents. This standard may be used by anyone as long as its source is specified. This standard, while it specifies the structures of other standards, does not supply them with specific content, since its level of abstraction is one level higher than any standard that would normally claim conformance. Where possible, this standard is conformant with itself (with respect to the core conformance test class, Clause 6 and Annex A.1)..."

Table of Requirements (examples):

Requirement: 2 Each component of the standard, including requirements, requirements modules, requirements classes, conformance test cases, conformance modules and conformance classes shall be assigned a URI as specified by the OGC naming authority or its equivalent.

Requirement: 3 Requirements on the use and interpretation of vocabulary shall be in the requirements class where that use or interpretation is used.

Requirement: 4 Each requirement in a conformant specification shall have a single standardization target type.

Requirement: 5 All conformance tests in a single conformance test class in a conformant specification shall have the same standardization target.

Requirement: 8 The requirements classes shall be in a one-to-one correspondence to the conformance test classes, and thus to the various certificate of conformance types possible for a candidate implementation.

Requirement: 9 A Conformance class shall not contain any optional conformance tests.

Requirement: 10 A certificate of conformance shall specify all parameter values used to pass the tests in its conformance test class.

Requirement: 11 A Conformance class shall explicitly test only requirements from a single requirements class.

Requirement: 12 A Conformance class shall specify any other conformance class upon which it is dependent and that other conformance class shall be used to test the specified dependency.

Requirement: 13 If a requirements class is imported from another standard for use within a specification conformant to this standard, and if any imported requirement is "optional," then that requirement shall be factored out as a separate requirements class in the profile of that imported standard used in the conformant specification. Each such used requirements class shall be a conformance class of the source standard or a combination of conformance classes of the source standard or standards.

Requirement: 14 For the sake of consistency and readability, all requirements classes and all conformance test classes shall be explicitly named, with corresponding requirements classes and conformance test classes having similar names.

Requirement: 15 Every specification shall define and identify a core set of requirements as a separate conformance class.

Requirement: 19 If any two requirements or two requirements modules are co-dependent (each dependent on the other) then they shall be in the same requirements class. If any two requirements classes are co-dependent, they are the same class.

Requirement: 39 A implementation passing the XML schema conformance test class shall first pass the core, specification conformance test class.

Requirement: 40 An implementation passing the XML schema conformance test class shall first pass the W3C Recommendation for XML schema.

Requirement: 41 If a specification conformant to the XML schema conformance class defines a set of data schemata, all components (e.g., elements, attributes, types...) associated with a single conformance test class shall be scoped to a single XML namespace.

Requirement: 42 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.

Requirement: 43 If a specification 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.

Requirement: 44 No requirements class in a specification conformant to the XML schema conformance class shall modify elements, types or any other requirement from a namespace to which it is not associated.

Requirement: 45 A specification 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.

Requirement: 46 Each sch:pattern element shall implement constraints described in no more than one requirement. Each requirement shall be implemented by no more than one sch:pattern.

Requirement: 47 Each sch:pattern element shall be contained within one sch:schema element.

Requirement: 48 The value of the sch:schema/@fpi attribute shall be a URI that identifies this implementation.

Requirement: 49 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.

Requirement: 50 The value of the sch:schema/@fpi attribute shall be used on only one Schematron schema.

Requirement: 51 A specification passing the XML meta-schema conformance test class shall first pass the core, specification conformance test class.

Requirement: 52 A specification passing the XML meta-schema conformance test class shall require that its specification targets (XML schema) pass the XML schema conformance class from this standard.

Prepared by Robin Cover for The XML Cover Pages archive.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	OGC Model for Writing Modular Specifications OGC Request for Comments on Candidate Specification Model Standard March 12, 2009. Wayland, MA, USA. [With Excerpts from the Specification] The membership of the Open Geospatial Consortium, Inc. (OGC) is requesting comments from the public on the candidate OGC Document, The OGC Specification Model: Writing Modular Specifications. This document, prepared by the Policy 1.0 Standards Working Group (SWG), derives from the collective experience of members in developing and implementing OGC standards, geospatial applications, platforms and services. It provides a logical model and template for candidate standards to assure their internal logic and conformance to accepted software development procedures and the OGC's policy and rules regarding the structure of standards and the types of information that they must provide. The policy guidance will make implementation of OGC standards and the construction of compliance tests easier through enforced traceability of requirements to implementation tests, and it will make modularization of both standards and implementations more explicit and consistent across dependent standards and implementations. This standard has been referred to as the "core and extension model" due to the insistence on a modular structure throughout all parts of a standard and its implementation. Eventually, all OGC standards will be transitioned to the new structure. This will help standardize the manner in which OGC standards are written and implemented, making implementations easier to test for compliance, thus improving interoperability between and swap-ability between implementations. The 30-day public comment period begins March 12, 2009 and closes on April 11, 2009. Comments will be reviewed and processed by the OGC Membership. The intent is to edit the Specification Model candidate standard and move the document to be an approved OGC standard. The Specification Model Request for Comment document can be downloaded from the OGC web site: http://www.opengeospatial.org/standards/requests/55 The OGC is an international consortium of more than 370 companies, government agencies, research organizations, and universities participating in a consensus process to develop publicly available geospatial standards. OpenGIS Standards support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT. OGC Standards empower technology developers to make geospatial information and services accessible and useful with any application that needs to be geospatially enabled. Visit the OGC website at http://www.opengeospatial.org/. Contact Sam Bacharach Executive Director, Outreach and Community Adoption Open Geospatial Consortium, Inc 35 Main Street, Suite 5, Wayland, MA 01778 USA Tel: +1-703-352-3938 Email: sbacharach@opengeospatial.org Excerpts from the Specification The Specification Model — Modular Specifications. Open Geospatial Consortium Inc. Publication date: 2009-03-11. SWG Internal Version: 23. SWG Internal Version Date: 2008-12-03. Reference number of this OGC project document: OGC 08-131r2. OGC Version: 1.0.1. Category: OGC Policy Standard. Editor: OGC Policy Standards Working Group (SWG). Status: SWG RFC Submission. 63 pages. Normative Annex A: Abstract Conformance Test Suite. Normative Annex B: Changes required in the OGC Standards; transition plan for incorporation into the OGC procedures. Informative Annex C: Definitions. Annex D: Bibliography. Download URIs: PDF, (Word .doc). Authors: Arliss Whiteside (BAE Systems C3I Systems), Paul Scarponcini (Bentley Systems, Inc), Simon Cox (CSIRO), David Danko (ESRI), Clemens Portele (Interactive Instruments GmbH), John R. Herring (Oracle USA), Andreas Matheus (University of the Bundeswehr — ITS), Richard Pearsall (US National Geospatial Intelligence Agency — NGA), Barry Reff (US Department of Homeland Security — DHS). Introduction. From the specification 'Introduction': [..] "A standard's usefulness and hence worth can be measured by: (1) The ease with which it can be implemented. (2) The number of times it has been implemented. (3) The number of times those implementations are used. (4) The ease with which those implementations interact. (5) The number of times it has been extended through inclusion in other useful standards. Some of these are affected by the choice of topic, but all are affected by the internal logical structure of the standard. This standard specifies generic rules for this internal structure conducive to being a true RUE ('really useful engine')..." "A standard is a partial solution to a design problem which limits solutions to enhance interoperability and harmony between disparate solution implementations. Design issues and requirements are transformed into statements about the solution design, and are then presented in the standard as requirements of the solution, usually as requirement statements targeting the solution. Thus, a standard presents requirements targeting implementations of solutions of the original problem, which must be satisfied the tests of the conformance suite. These tests are organized into conformance classes, each of which represents a mechanism for partial satisfaction of the standard. These give the standard a modular structure, each requirements class represented by a conformance class. In a well written standard, the normative clauses and any model or schema are organized in a manner that parallels the conformance clause..." Scope. From the specification 'Scope': Scope: This standard specifies some desirable characteristics of a standards specification that will encourage implementations by minimizing difficulty, mimicking implementation structure and optimizing usability and interoperability. Clause 6.1 contains the model of a standard upon which this standard is described. Annex C contains informal and non-normative definitions ordered for ease of understanding. These two sections can be read first to aid in the understanding of the rest of the document... Conformance. From the specification 'Conformance' section: There are five conformance classes for this standard: Specification documents in general (the core) — see Clause 6 and Annex A.1 2. Specifications using UML to state requirements, extending the core — see Clause 7.2.2 and Annex A.2 3. Specifications using XML schema to state requirements, extending the core — see Clause 7.2.3 and Annex A.3. Specifications using Schematron to state requirements, extending XML schema — see Clause 7.2.4 and Annex A.4 5. Specifications defining requirement for a new category of XML schemas, extending the core, whose target XML schemas must be conformant with the XML schema conformance class above — see Clause 7.2.5 and Annex A.5. Foreword. From the specification 'Foreword': "This standard began as discussions in the OGC Architecture Board (OAB) about general principals of application development taken from the OAB members' collective experience. Since this standard is a summary of collective experience, no one should claim intellectual property rights to its contents. This standard may be used by anyone as long as its source is specified. This standard, while it specifies the structures of other standards, does not supply them with specific content, since its level of abstraction is one level higher than any standard that would normally claim conformance. Where possible, this standard is conformant with itself (with respect to the core conformance test class, Clause 6 and Annex A.1)..." Table of Requirements (examples): Requirement: 2 Each component of the standard, including requirements, requirements modules, requirements classes, conformance test cases, conformance modules and conformance classes shall be assigned a URI as specified by the OGC naming authority or its equivalent. Requirement: 3 Requirements on the use and interpretation of vocabulary shall be in the requirements class where that use or interpretation is used. Requirement: 4 Each requirement in a conformant specification shall have a single standardization target type. Requirement: 5 All conformance tests in a single conformance test class in a conformant specification shall have the same standardization target. Requirement: 8 The requirements classes shall be in a one-to-one correspondence to the conformance test classes, and thus to the various certificate of conformance types possible for a candidate implementation. Requirement: 9 A Conformance class shall not contain any optional conformance tests. Requirement: 10 A certificate of conformance shall specify all parameter values used to pass the tests in its conformance test class. Requirement: 11 A Conformance class shall explicitly test only requirements from a single requirements class. Requirement: 12 A Conformance class shall specify any other conformance class upon which it is dependent and that other conformance class shall be used to test the specified dependency. Requirement: 13 If a requirements class is imported from another standard for use within a specification conformant to this standard, and if any imported requirement is "optional," then that requirement shall be factored out as a separate requirements class in the profile of that imported standard used in the conformant specification. Each such used requirements class shall be a conformance class of the source standard or a combination of conformance classes of the source standard or standards. Requirement: 14 For the sake of consistency and readability, all requirements classes and all conformance test classes shall be explicitly named, with corresponding requirements classes and conformance test classes having similar names. Requirement: 15 Every specification shall define and identify a core set of requirements as a separate conformance class. Requirement: 19 If any two requirements or two requirements modules are co-dependent (each dependent on the other) then they shall be in the same requirements class. If any two requirements classes are co-dependent, they are the same class. Requirement: 39 A implementation passing the XML schema conformance test class shall first pass the core, specification conformance test class. Requirement: 40 An implementation passing the XML schema conformance test class shall first pass the W3C Recommendation for XML schema. Requirement: 41 If a specification conformant to the XML schema conformance class defines a set of data schemata, all components (e.g., elements, attributes, types...) associated with a single conformance test class shall be scoped to a single XML namespace. Requirement: 42 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. Requirement: 43 If a specification 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. Requirement: 44 No requirements class in a specification conformant to the XML schema conformance class shall modify elements, types or any other requirement from a namespace to which it is not associated. Requirement: 45 A specification 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. Requirement: 46 Each `sch:pattern` element shall implement constraints described in no more than one requirement. Each requirement shall be implemented by no more than one `sch:pattern`. Requirement: 47 Each sch:pattern element shall be contained within one sch:schema element. Requirement: 48 The value of the `sch:schema/@fpi` attribute shall be a URI that identifies this implementation. Requirement: 49 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. Requirement: 50 The value of the `sch:schema/@fpi` attribute shall be used on only one Schematron schema. Requirement: 51 A specification passing the XML meta-schema conformance test class shall first pass the core, specification conformance test class. Requirement: 52 A specification passing the XML meta-schema conformance test class shall require that its specification targets (XML schema) pass the XML schema conformance class from this standard. Prepared by Robin Cover for The XML Cover Pages archive.