"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Specialization by restriction

Contents

Related pages



Background

It is sometimes desirable to define a class that is related to an existing more generalized class by restriction. In this scenario an instance of the specialized class is a valid instance of the parent, but there are additional constraints on its form, for example
  • restricting the cardinality of a property, including making an optional property mandatory
  • restricting the value space of a property, such as requiring that a text value be taken from a specified dictionary
  • constraining the type of a property whose type is a wildcard or a large inheritance hierarchy/substitution group

This is formally described as a "profile" (ISO 19106) and is a typical pattern encountered when one wants to deploy an instance of a common behaviour (i.e. something supported by generic software).

There are other aspects of profiles, explored more thoroughly in ApplicationProfiles, with application to MetadataProfiles, ServiceProfiles and ObservationsProfiles.

XML Schema implementation

This pattern is implemented in W3C XML Schema as "derivation by restriction" and there are some worked examples in XmlSchemaDerivationByRestriction.

Pure XSD implementations forces a "clone-and-modify" pattern, where a (partial) copy of the schema in an imported namespace is republished with restrictions. This leads to significant problems, both in the overheads for complex schemas, and in the maintenance - any changes in the original schema will require significant effort to propagate to the derived implementation.

Clone-and-modify also becomes extremely problematic for any implementing technology - for example a technology that caches significant portions of the GML schemas could no longer trust that any new reference is the same as the cached components, forcing a reload of the entire schema tree every time a new schema is encountered. The client also needs the ability to maintain multiple copies of objects with the same identifier, violating the basic precepts of namespace usage. Clearly this is problematic.

UML Implementation

This pattern can be implemented in UML by re-declaring the property (attribute, operation, association-role) on the specialized class with a new type/cardinality/signature which overrides the type/cardinality/signature of the element inherited from the parent. Of course it only matches the "restriction" semantics if the new type is a specialization of the original, or new cardinality is a valid subset of the original etc. Furthermore, in UML it is quite possible to mix overrides and extension in a single step. This is OK as UML is a conceptual schema language, whose capabilities are in general unconstrained by implementability concerns!

But since we do have to deal with the latter in the real world, we use a profile (subset) of UML that limits the variability. The GML spec tightens this further in its UML - XML conversion rules.

In particular, use of the "override" mechanism is not supported. However, we often want to model exactly that sort of restriction, whilst leaving the srtructural aspects of the implementation (XML) schema intact (without redefining elements or clone-and-modify the original namespace.

To be continued - heading toward capturing the consensus of the discussion started on Bryan Lawrence's blog.

See MetadataProfiles#Application_example

 
Topic revision: r7 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).