Skip to content

Commit

Permalink
Minor editorial fixes
Browse files Browse the repository at this point in the history
  • Loading branch information
3DXScape committed Jun 22, 2022
1 parent c81588f commit 18627ed
Show file tree
Hide file tree
Showing 3 changed files with 4 additions and 6 deletions.
2 changes: 1 addition & 1 deletion standard/standard/clause_1_scope.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ The OGC GeoPose 1.0 Standard defines requirements (rules) for the interoperable
* An advanced form with more flexibility for more complex applications, and
* Composite GeoPose structures to support time series chain, and graph structures.
The GeoPose Standard is based on an implementation-neutral Logical Model(LM). This LM is a formalization of a Conceptual Model(CM). The CM consists of a linked set of terms and definitons, defining a domain odf discourse for the various geometrric, geographic, and physical concepts related to GeoPoses. The LM formalizes the relationships between the implementable parts and aspects of the CM. The LM further establishes the structure and relationships between GeoPose components and also between GeoPoses data objects themselves in composite structures.
The GeoPose Standard is based on an implementation-neutral Logical Model (LM). This LM is a formalization of a Conceptual Model (CM). The CM consists of a linked set of terms and definitons, defining a domain odf discourse for the various geometrric, geographic, and physical concepts related to GeoPoses. The LM formalizes the relationships between the implementable parts and aspects of the CM. The LM further establishes the structure and relationships between GeoPose components and also between GeoPoses data objects themselves in composite structures.

Note that the concrete GeoPose data objects defined by this standard correspond to only certain classes and properties of the LM. These classes and properties are identified as implementation-neutral Structural Data Units (SDUs). SDUs are aliases for the implementable elements of the LM. SDUs are grouped to define the implementation-neutral form of the GeoPose Standardization Targets: the specific implementation that the Standard addresses. For each Standardization Target, each implementation technology will have the definition of the encoding or serialization specified in a manner appropriate to that technology.

Expand Down
6 changes: 2 additions & 4 deletions standard/standard/clause_2_conformance.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -4,17 +4,15 @@

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (Normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies (https://portal.ogc.org/files/?artifact_id=55234) and Procedures and the OGC Compliance Testing web site (https://www.ogc.org/compliance). GeoPose 1.0 JSON encodings are specified via JSON-Schema:2019-9 and most of the requirements are that conforming encoded data objects shall validate against the corresponding schema.

In order to conform to this OGC® Standard, a software implementation shall choose to implement any one or more of the eight Standardization Targets specified in Annex A (normative).

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

=== Modularity

This standard describes eight Standardization Targets. These targets are independent and a conforming implementation may implement one or more of the targets.
This standard describes eight standardization targets. These targets are independent and a conforming implementation may implement one or more of the targets.

=== Conformance Classes

This standard identifies eight conformance classes. One conformance class is defined for each corresponding set of Structural Data Units (SDUs) where each SDU is linked to the Logical Model as an alias for a class or attribute. Additionally, each of the eight standardization targets is represented by a conformance class as defined by a corresponding requirements class.
This OGC® standard identifies eight conformance classes. One conformance class is defined for each corresponding set of Structural Data Units (SDUs) where each SDU is linked to the Logical Model as an alias for a class or attribute. Additionally, each of the eight standardization targets is represented by a conformance class as defined by a corresponding requirements class.
The tests in <<abstract-test-suite,Annex A>> are organized by requirements class. An implementation of a conformance class must pass all tests specified in Annex A for the corresponding requirements class.

No conformance class has a dependency on another conformance class.
Expand Down
2 changes: 1 addition & 1 deletion standard/standard/models/conceptual_model.adoc
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
The GeoPose Conceptual Model(CM) consists of linked definitions of terms denoting concepts expressed in the GeoPose LM and structural data unit(SDU) specifications for the standardization targets. The CM describes a (non-normative) domain of discourse for terms used in defining a precise and normative Logical Model(LM) expressed as a Unified Modelling Language (UML) class diagram.

The scope of the standardization targets is a subset of the scope of the LM. The scope of the LM is a subset of the scope of the Conceptual Model. The standardization targets are mutually independent implementations of subsets of the LM. The standardization targets are expressed in Extended Backus-Naur Form where all terminal symbols reference attributes of classes in the LM.
The scope of the standardization targets is a subset of the scope of the LM. The scope of the LM is a subset of the scope of the Conceptual Model. The standardization targets are mutually independent implementations of subsets of the LM.


“Conceptual model: a description of common concepts and their relationships, particularly in order to facilitate exchange of information between parties within a specific domain [CEN ENV 1613:1994]. A conceptual model is explicitly chosen to be may be informed by, but independent of design or implementation concerns.”
Expand Down

0 comments on commit 18627ed

Please sign in to comment.