Copyright © 2014 Open Geospatial Consortium
74
swe:field xlink:href
= http:www.my.comfields.xmlTEMP
Typically, “xlink” references will be specified as resolvable URLs. 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.netspecsensorml2.0reqxmlcore-processref-or-inline-value-present
Req 46. A property element supporting the “swe:AssociationAttributeGroup” shall either contain the value inline or populate the “xlink:href” attribute with a valid
reference, but shall not be empty.
As later specified, further requirements may be placed on the use of objects reference by xlink. This includes in some case, the use of both xlink:href to provide a resolvable link
to the object’s description as well as the use of an xlink:title to provide the uniqueID of the object. Particular properties ay also require the application of xlink:role or
xlink:arcrole to provide the absolute and relative role of the object, respectively.
8.1.1.3 Extensibility Points
The SensorML schemas define extensibility points that can be used to insert ad-hoc XML content that is not specified by this standard. This is done via optional “extension”
property 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 for many properties in a SensorML 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 to define 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. However, it should be
recognized that 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 such extensions of the XML schema described in this standard will 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.
SensorML OGC 12-000
Copyright © 2014 Open Geospatial Consortium
75
Requirement
http:www.opengis.netspecsensorml2.0reqxmlcore-processextension-namespace-unique
Req 47. The value of the extension property shall be a schema in which the root element is defined in a new unique namespace other than the namespaces used
by this standard and its dependencies.
Extensions are not allowed to change the meaning or behavior of elements and types defined by this standard in any way in this case, new classes or properties will be
defined. This guarantees that implementations, which may have no knowledge of an extension, can still properly use XML instances containing these extensions.
Requirement
http:www.opengis.netspecsensorml2.0reqxmlcore-processextension-coherent-with-core
Req 48. The value of the extension property shall not redefine or change the meaning or behavior of XML elements and types defined in this standard.
The execution of the process should not depend on information contained within an extension. Data values required for process execution will be provided within the input,
output, and parameter properties, and within the SensorML and SWE Common Data namespace elements i.e. sml and swe, respectively, and cannot exclusively be contained
in the extension classes.
Requirement
http:www.opengis.netspecsensorml2.0reqxmlcore-processextension-process-execution
Req 49. The value of the extension property shall not exclusively contain information required for the successful execution of the process.
Note that extension points are also supported by the SWE Common Data specification such that community-specific XML elements can be added to any property value that
uses a SWE Common data type element as its value. Common anticipated applications of property-specific extension points include security tagging of individual properties and
community-specific quality control characterization of property values.
8.1.2 General XSD Dependencies and XML Heading
