SWECommon CR - Improve Extensibility Mechanisms
Open Geospatial Consortium
Document OGC 08-020
CR-Form-v3
CHANGE REQUEST
SWE Common
CR ?
rev
-
Current version:
1.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Impl Stand X
Best Practices Paper
Title:
Improve Extensibility Mechanisms
Source:
Alexandre Robin, Ingo Simonis, Johannes Echterhoff, Michael E. Botts
Work item code:
Category:
Other
Date: 2008-02-25
C (Functional modification of feature)
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Reason for change:
Current method for extending SWE Common by deriving new hard typed
structures can break interoperability when using generic software since there
can be ambiguous situations.
Summary of change: Addition of new DerivableXXX types in the schema forcing the tagging of Data
Components and DataRecord fields with appropriate attributes. This change
is backward compatible.
Consequences if
not approved:
Without this change the implementation of a generic SWE Common parser is
much harder and will lead to less robust software.
Clauses affected:
9.2.1 (currently in SensorML 1.0 07-000)
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
1
OGC 08-020
Other specs
X Other core specifications
Affected:
SensorML 1.0 - 07-000
Abstract specifications
Best Practices Papers
Supporting Doc.
Other comments:
Status
NEW
Disposition
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
2
OGC 08-020
Change Request Description
1. Add statement in the specification to force the derivation of new hard typed data
components from specialized schema types (DerivableXXXType), so that derived
objects are appropriately tagged with their base type (i.e. record, array, field…)
2. Several objects in the schema will have to be derived using this mechanism
(SimpleDataRecord, ConditionalValue, ConditionalData, Vector, SquareMAtrix,
etc…)
3. Add examples of derived structures such as geometries. These geometry objects
will be based on ISO 19107.
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
3
Document OGC 08-020
CR-Form-v3
CHANGE REQUEST
SWE Common
CR ?
rev
-
Current version:
1.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Impl Stand X
Best Practices Paper
Title:
Improve Extensibility Mechanisms
Source:
Alexandre Robin, Ingo Simonis, Johannes Echterhoff, Michael E. Botts
Work item code:
Category:
Other
Date: 2008-02-25
C (Functional modification of feature)
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Reason for change:
Current method for extending SWE Common by deriving new hard typed
structures can break interoperability when using generic software since there
can be ambiguous situations.
Summary of change: Addition of new DerivableXXX types in the schema forcing the tagging of Data
Components and DataRecord fields with appropriate attributes. This change
is backward compatible.
Consequences if
not approved:
Without this change the implementation of a generic SWE Common parser is
much harder and will lead to less robust software.
Clauses affected:
9.2.1 (currently in SensorML 1.0 07-000)
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
1
OGC 08-020
Other specs
X Other core specifications
Affected:
SensorML 1.0 - 07-000
Abstract specifications
Best Practices Papers
Supporting Doc.
Other comments:
Status
NEW
Disposition
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
2
OGC 08-020
Change Request Description
1. Add statement in the specification to force the derivation of new hard typed data
components from specialized schema types (DerivableXXXType), so that derived
objects are appropriately tagged with their base type (i.e. record, array, field…)
2. Several objects in the schema will have to be derived using this mechanism
(SimpleDataRecord, ConditionalValue, ConditionalData, Vector, SquareMAtrix,
etc…)
3. Add examples of derived structures such as geometries. These geometry objects
will be based on ISO 19107.
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
3