Skip to content

Commit

Permalink
Update encoding to model-based approach
Browse files Browse the repository at this point in the history
  • Loading branch information
@manuelfuenmayor @ronaldtse
manuelfuenmayor authored and ronaldtse committed Jun 25, 2024
1 parent f6bccc8 commit 3aa06d8
Showing 1 changed file with 11 additions and 196 deletions.
207 changes: 11 additions & 196 deletions sources/sections/ac-definitions.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -67,220 +67,35 @@ in <<cls-6-1>>. The following subclauses describe the classes shown in this UML
class diagram.

=== Specification

A specification, to become a standard must be approved by an authority, such as ISO
or OGC. This gives the specification a namespace corresponding to the standards
authority. Thus the name of the specification is usually a local name in this
namespace: for example "ISO 19107: Geographic Information -- Spatial schema" is an
approved specification of ISO TC 211 (the authority as a TC under ISO). The parts of
the name that give this are "ISO" and "Geographic Information". The local name
within this namespace is "19107: Spatial schema". This syntax is not usual for
namespaces where the namespace name is usually either a prefix or suffix of the
local name. GenericName, LocalName, Namespace are all types described in "ISO 19103:
Geographic information -- Conceptual schema language". The attributes of a
Specification describe its local name, its authority, the date of publication and
its current status (such as CD, DIS, IS in ISO, or Draft, Candidate Standard or
Standard in OGC).

[source%unnumbered]
----
Class Specification
{
name : String // name for the standards
authority : Principal // Standards Body & Namespace for name
date : DateTime // publication date
status : String // description of current status
reference : Specification[0..*] // other standards used normatively
testSuite : ConformanceSuite // all tests associated to the standard
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, Specification, skip]

=== Conformance Suite

The unique conformance suite of a specification lists the tests (grouped into
conformance test classes consisting of some number of conformance test modules,
containing some number of conformance tests) that allow testing of an implementation
of the specification for conformance with the specification. Every specification
needs one of these suites, or conformance cannot be claimed with proof. In ISO and
OGC, the conformance suite included in the specification is usually an abstract
description of the tests which will be implemented. Other standards may use a more
concrete description. For the purposes of this OGC standard, the precise nature of
the conformance suite is not particularly important as long as it is not ambiguously
stated.

Each conformance test within a conformance class should be against a single
standardization target defined for that class. A conformance suite may contain
several defined conformances classes for the same standardization target.

[source%unnumbered]
----
Class ConformanceSuite
{
class : ConformanceClass[1...*]
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, ConformanceSuite, skip]

[[conformance-class]]
=== Conformance Class

The requirements in the requirements classes of a specification have to be tested
and the conformance classes are the containers for these tests' definition. The
requirements classes will have interdependencies, and this is reflected in the
explicit dependencies between the conformance classes. If class "stem:[a]" is
dependent on class "stem:[b]", then to pass the test for "stem:[a]" a
standardization target must also pass the test for "stem:[b]." The class name is
shared with its corresponding requirements class.

[source%unnumbered]
----
Class ConformanceClass
{
name : String // name of the conformance class
dependency : ConformanceClass[0...*] // other classes that must be passed
// if this one is to be passed
// (consistent with Requirements class)
requirement : RequirementClass
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, ConformanceClass, skip]

=== Requirements class

The specification requirements classes (usually realized as clauses in the
specification document) segment the requirements in the specification in a manner
consistent with the conformance classes. Since the requirements class and the
conformance class will eventually be referred to in a certification of conformance,
they should have names, probably in the namespace defined by the specification's
name and authority.

[source%unnumbered]
----
Class RequirementsClass
{
name : String // name of the conformance class
dependency: RequirementsClass [0...*] // dependent requirements classes
module : RequirementsModule[1...*] // subsets of this requirementClass
targetType: StandardizationTargetType
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, RequirementsClass, skip]

=== Requirements module

The specification requirements modules (usually realized as subclauses of the
requirements class in the specification document) segment the requirements in the
specification in a manner consistent with the conformance test modules.

[source%unnumbered]
----
Class RequirementsModule
{
name : String
requirement: Requirement[1...*]
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, RequirementsModule, skip]

=== Normative Statement

The normative statements, either requirements or recommendations of a standard, are
organized into the requirements modules and classes, and may be tested by the
conformance tests in their requirements class's corresponding conformance class. If
tested, the statement is a "Requirement", and if not tested the statement is a
"Recommendation."

[source%unnumbered]
----
Class NormativeStatement
{
name : String // name the requirement
test : ConformanceTest[1...*] // corresponding conformance test
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, NormativeStatement, skip]

=== Requirement

Each normative statement which is tested by any conformance test is a requirement.

[source%unnumbered]
----
Class Requirement inherits NormativeStatement
{
test : ConformanceTest[1...*] // corresponding conformance test
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, Requirement, skip]

=== Recommendation

A normative suggestion which will not be directly tested is a "Recommendation."
Recommendations have a variety of uses, for example:

. Legal restriction, such as "not for commercial use" or "for planning purposes."
These allow the specification to restrict use of its implementation to
standardization targets for which it was designed.
. Statement of best practices. These are included as suggestions for logical designs
that may implement the requirements in the same module.

Regardless of their use, Recommendations are not tested since they are not required
of all conformant implementations.

[source%unnumbered]
----
Class Recommendation inherits NormativeStatement
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, Recommendation, skip]

=== Conformance test

The requirements in a specification have to be tested and the conformance test
specification contains the test's definition. In this standard, conditional tests,
based on a requirement with some precondition, have as part of their execution the
task of creating the precondition in which they will be tested. If the condition is
not creatable, then the test is not required to be executed.

[source%unnumbered]
----
Enumeration TestType
{
basic
capabilities
}
Class ConformanceTest
{
testPupose : String
testMethod : String
Reference : String
testType : TestType
requirement : Requirement[1...*]
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, ConformanceTest, skip]

=== StandardizationTarget

Each conformance class (and hence requirements class) is targeted to a particular
type of implementation. An implementation testable by a conformance class is a
StandardizationTarget of that class, and (once the appropriate test have been
passed) can carry a certificate indicating its conformance to a requirements class
proved by the tests in the conformance class.

[source%unnumbered]
----
Class StandardizationTarget
{
conformanceCertificates : String[0...*] // conformance classes passed
// by this target
type : StandardizationTargetType
}
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, StandardizationTarget, skip]

=== StandardizationTargetType

A Standardization Target Type is the type or collection of standardization targets
testable by the conformance class corresponding to a requirements class. This is a
&laquo;metaclass&raquo; in the sense that it defines a type of implementation with members of
the type testable by a particular conformance class. This is a "multiple
classification" scheme, since each target may be a member of multiple
StandardizationTargetTypes.

[source%unnumbered]
----
Abstract Metaclass StandardizationTargetType
// description of the standardization targets in this type
----
[lutaml_uml_attributes_table,models/metanorma-requirements-models/views/ogc-modspec.lutaml, StandardizationTargetType, skip]

0 comments on commit 3aa06d8

Please sign in to comment.