SWE Common Data Model OGC 08-094r1
- Use of “soft-typed” properties. These properties are encoded as XML elements
with a generic element name but provide a “name” attribute for further disambiguation.
- Encoding of certain properties as XML attributes. This type of encoding adds to the
“element-only” rules defined by ISO 19136. It is restricted to properties with a primitive type and indicated by a new tagged value in the UML model.
- Use of a new abstract base type. A custom base type called “AbstractSWEType” is
used for all complex types. Following ISO 19136 encoding rules, each UML class with a Type or
DataType stereotype, or no stereotype at all, is implemented in the schema as a global XML complex type with a corresponding global XML element called object
element. Each of these elements has the same name as the UML class i.e. always UpperCamelCase and the name of the associated complex type is a concatenation of this
name and the word “Type”.
Each UML class attribute is implemented either as a global complex type and a corresponding local element called property element, or as an XML attribute. Each
property complex type is given a name composed of the UML attribute name always lowerCamelCase and the words “PropertyType”. The element is defined locally within
the complex type representing the class carrying the attribute and named exactly like the attribute in UML i.e. no global elements are created for class attributes. Class
associations are implemented similarly except they cannot be implemented as an XML attributes.
8.1.1.2 IDs and Linkable Properties
The schemas defined in this standard make extensive use of “xlink” features to support hypertext referencing in XML. This allows most property elements to reference content
either internally or externally to the instance document, instead of including this content inline. This is supported by extensive use of the “id” attribute of type xs:ID on most
object elements, and of the “swe:AssociationAttributeGroup” attribute group, on most property elements.
In properties that support “xlink” attributes, one can usually choose to define that property value inline, as in:
swe:field swe:Quantity
id =
TEMP …
swe:field
One can then reference an object within the same document by its ID:
swe:field xlink:href
= TEMP
Copyright © 2011 Open Geospatial Consortium
67
OGC 08-094r1 SWE Common Data Model
An object within an external document can also be referenced by including the full URI:
swe:field xlink:href
= http:www.my.comfields.xmlTEMP
Typically, “xlink” references will be specified as URLs or as URNs that can be easily resolved through registries. It is required that the property has either the “xlink:href”
attribute set or contain an inline value, even though this cannot be enforced by XML schema.
Requirement
http:www.opengis.netspecSWE2.0reqxsd-simple-componentsref-or-inline-value-present
Req 59. A property element supporting the “swe:AssociationAttributeGroup” shall
contain the value inline or populate the “xlink:href” attribute with a valid reference
but shall not be empty.
8.1.1.3 Extensibility Points
The SWE Common Data Model schemas define extensibility points that can be used to insert ad-hoc XML content that is not defined by this standard. This is done via optional
“extension” elements of type “xs:anyType” in the base abstract complex type “AbstractSWEType”. Since all object types defined in this standard derive from this base
type, extensions can be added anywhere in a SWE Common instance.
This mechanism allows for a “laxist” way of including extended content in XML instances as the extended content is by default ignored by the validator. However, it is
also possible to formally validate extended content by writing an XML schema for the extension and feeding it to the validator via the “xsi:schemaLocation” attribute in all
instances using the extension.
The recommended way of extending the XML schema of this standard is by defining new properties on existing objects by inserting them in an “extension” slot. Additionally this
should be done in a way that these new properties can be safely ignored by an implementation that is not compatible with a given extension. Defining new XML object
elements such as new data component objects rather than new properties will greatly reduce forward compatibility of implementations compliant to this standard with XML
instances containing extensions of this standard.
In any case, all extensions of the XML schema described in this standard shall be defined in a new namespace other than the namespaces used by this standard and its
dependencies in order to allow easy detection of extensions by implementations.
68
Copyright © 2011 Open Geospatial Consortium
