"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"

FAQ on schema techniques and encoding patterns

Contents

Related pages



Deriving new XML components based on pieces from another namespace

I am currently trying to produce an XML schema document that would be returned as a response to a DescribeFeatureType request. I'm basing it on the example XML document you came up with when you were over here (which I've attached for reference, as well as my attempt at the schema document so far which might give you an idea of how confused I am).

If I reference a class in GML eg gml:ObservationType in the schema am I restricted to only those elements defined in the gml namespace type?

Eg. The ObservationType in GML is defined as

 <complexType name="ObservationType">
    <complexContent>
     <extension base="gml:AbstractFeatureType">
      <sequence>
        <element ref="gml:timeStamp" /> 
       <element ref="gml:using" minOccurs="0" /> 
       <element ref="gml:target" minOccurs="0" /> 
       <element ref="gml:resultOf" /> 
     </sequence>
     </extension>
    </complexContent>
   </complexType>

But in our case the observation also includes, for example, a confidence rating and also an indication of whether this is a preferred set of results. So do I use a modified definition of the above (and if so how do I add to it) or do I not worry about it and simple create my own class for observations?

-- StuartGirvan - 15 May 2003

What you do is construct a new schema (targetting the XMML namespace) within which you define a new XML Schema complexType "MyObservationType", which extends the gml:ObservationType with a containing the additional properties (sub-elements) required for your application. Just like gml:ObservationType extends gml:AbstractFeatureType in the example below. This is the main inheritance method within XML Schema.

The reason it is in a different namespace is that you do not have the right to add new components to the GML namespace. The XML instances that correspond to an element declared with the new type will have a sequence of sub-elements ("properties") some of which are from the GML namespace, and some of which will be from the XMML namespace.

Look at the examples in clause 7 and annex C of the Observations and Measurements spec to see how this multiple namespace stuff works.

Note that these are XML Schema questions more than GML/XMML questions.

-- SimonCox - 15 May 2003

See also the revised Observation Type in XmmlCVS:XMML/commonFeatures.xsd

-- SimonCox - 24 Jul 2003

Deriving from Properties vs Deriving from Objects

What are the design principles behind deriving from properties vs. deriving from objects? For example, in XmmlCVS:XMML/base.xsd, xmml:measurementStatus, xmml:recordStatus and xmml:reference are all derived from and substitutable for gml:metaDataProperty. On the other hand there are a number of object elements 'derived' directly or indirectly from gml:_MetaData such as: xmml:AccessRestrictions, xmml:EventMetaData, xmml:RecordMetaData, xmml:MeasurementMetaData etc.

Thus it is possible, for example, for a borehole to have a property xmml:measurementStatus with value an xmml:MeasurementMetaData object, or for it to have a property gml:metaDataProperty with value the same xmml:MeasurementMetaData object. It is not clear to me that there is any semantic difference between these two (the former is clearer) and the variation in implementation seems more confusing than helpful.

On a more general note, as features are essentially defined by what properties they can have, I wonder if having too much substitutability of property types is something to be avoided as a general rule? I have some similar questions about xmml:relatedFeature.

-- MarcusSen - 17 Jul 2003

This raises some subtle design issues. The situation is described correctly. The properties specialised from metaDataProperty limit the allowed content, but substitutability is valid at either the gml:metaDataProperty or gml:_MetaData level.

The one capability that this provides is the possibility of enforcing certain MetaData to be present, by deriving new Feature/Object types where the specialised metaDataProperty is introduced in a restriction of the parent type. In practice this means that all the metaDataProperty's, generic or specialised, occur in a block at the top. Alternatively, the same specialised metaDataProperty could be simply added as part of the content model further down, rather than substituted at the top.

Is it worth it? Possibly not.

Your point about over-using substitutability is also good. In GML substitution groups are the primary mechanism used to expose class hierarchies. While it is clear that Objects/Features pretty much always belong in hierarchies, with property elements this may not be the case.

For example, the generic xmml:relatedFeature is useful. And clearly if Observations, Stations, Specimens etc are Features, then relatedObservation etc might be substitutable for relatedFeature. And the reason we may need relatedObservation is when we know that there is likely to be one, and we want it clearly labelled rather than just hidden inside a "generic" relatedFeature. At which time the relatedObservation should be added explicitly to the content model. But other times there is a related Observation/Station/Specimen to be recorded it should simply be the content of a xmml:relatedFeature. I guess I just argued round to why, even though Observations is substitutable for Feature, there is no compelling case for relatedObservation element being substitutable for relatedFeature. Thanks.

There is a pattern here: Object/Feature substitutability is useful, but property substitutability mostly not. This mirrors a discussion we had in the GML RWG where there was an attempt to abandon property derivations altogether. We found, however, that it doesn't work all the time, because of the interaction between (XML Schema derivation by restriction) and the (GML Object-property model). The conclusion in the end was that property derivation is tricky, often unnecessary, so should only be used when unavoidable.

Note that the "derivation by restriction" mechanism in XML Schema allows you to derive specific content models from more generic versions by specifying which descendant is used for various content elements. However, this inheritance method, where the content is restricted relative to the parent, rather than extended, is not part of the standard UML meta-model, so OCL has to be used to augment UML for this construction. Perhaps there is a message here.

-- SimonCox - 18 Jul 2003

Derivation by Restriction and Optional Properties

The Using UML book that I am currently using to teach myself something of object oriented design methodology has the following statement:

"A subclass is an extended, specialized version of its superclass. It includes the operations and attributes of the superclass, and possibly some more."

and a note:

"A few languages, notably Eiffel, also permit subclasses to delete attributes or operations of a superclass - but this is now normally considered a bad idea."

These would seem to suggest that XML Schema derivation by restriction is not to be favoured. However, it is also made clear that the essential property that a sub-class must satisfy is that any code designed to work with an object belonging to a particular class must also work when given an object belonging to a sub-class instead.

An XML Schema restriction can only get rid of attributes or sub-elements etc. where they were optional in the original class so that any code dealing with instances of the orignal class must have been able to deal with their absence already. Thus from the substitutability criterion XML Schema derivation both by extension and by restriction are valid sub-classing mechanisms.

(It isn't common in programming languages that I'm aware of to be able to define an attribute of a class as optional so I guess this is why restriction doesn't tend to happen in these and maybe this is why UML doesn't deal with it.)

Derivation by restriction seems very useful to me and my conclusion is that UML on it's own is lacking. However, maybe a problem that it might be symptomatic of in some cases is where the base class just has too many optional attributes or alternative choices? If a class is extremely flexible about its content it maybe difficult for any code to do anything useful with it.

(Consideration of when sub-classes are conceptually sub-classes rather than just happening to share attributes is another thing to bear in mind.)

-- MarcusSen - 18 Jul 2003

Yes - in some cases the base classes do end up with perhaps too many "optional" properties. It is probably cleaner and easier to follow derivation if required properties are added rather than not-required ones deleted. The challenge is then to ensure that they are added in the same way by all possible specialised classes.

Regarding the structural vs. conceptual inheritance question: I raised this with John Herring abour a year ago. I noticed that many of the models in the ISO 191** series have quite deep inheritance hierarchies, in which the top several layers do not actually add any UML attributes to the classes. They are tracking conceptual or semantic relationships rather than content models. John assured me that this was in fact the right way to do it, in UML at least.

However, mapping this straight into XSD means that we can end up with rather long substitution group chains to match.

-- SimonCox - 24 Jul 2003

Chipping in as an experienced OO programmer now helping Simon, I find it interesting how the XML Schema community are retracing some of the lessons of the OO design community's last 15 years smile I also expect some of my naive comments are going to embarrass me, hopefully without upsetting the experienced schemers amonst us.

When I first read about XML Schema's subclassing by restriction model, I immediately thought it was badly named. I'm used to subclasses adding behaviour. I thus find it much easier to think of restrictions as *adding rules.*

I'd like to run some of the metrics developed for OO model quality over some of our deeper XML Schemas and see if that makes any sense, perhaps as part of my current BuildBot project.

-- AndyDent - 23 Dec 2003

In OO, derivation by restriction usually means adding a constraint to a property, such as a bounds constraint on a number, or specialisation of a member sub-object. This type of heirarchy is called a constraint heirarchy, and is generally a good idea. In this case, the sub-class is a specialisation of the super-class. OOers generally do not understand restriction to mean actual deletion of (optional) class members or attributes, and the latter is so rarely used, I don't know the name for it.

-- PeterHornby - 24 Dec 2003

For the programmers amongst us, stop thinking of the members of an XML-Schema object and think of them as being virtual functions which return either a piece of data or nil. That may make more sense to say, a subclass can stop returning data and return nil. This polymorphic behaviour is a much better fit for what happens when you have a subclassed object derived by restriction. -- AndyDent - 29 Nov 2004

Importing XML Modules into your Application Schema

A well-designed XML exchange file consists of XML modules. When designing a schema, you should design a module so that it is 1. standalone and independent. 2. pluggable 3. replaceable.

The issue is from two perspectives. The first is from the perspective of a developed who wants to leave a "slot" for a module. For example, I have a well header module, which has a slot for well associates. Examples of well associates would be the well operator, royalty owner(s), regulatory bodies, drilling contractors. Etc. By leaving a slot, I am passing on the need to develop a full schema for these associates. I am also saying that you can use my business associate module, or yours, or anyone elses that suits your needs.

The second perspective is from a user of modules. She must know how to insert the modules into her schema (which may be developed around other modules) in a consistent manner. There are a lot of issues here that I cannot discuss in this short note.

There is a paper at http://www.posc.org/ComponentDocs/ImportingModules.doc that discusses the issues more fully.

Now...to the GML part. I have a template which calls for three modules. They are a lease (an area of land, and subsurface, that allows the leaseholder to drill and produce hydrocarbons), a well, and a business associate. I also have a table (which is a complex property) of production information. The lease and well are both candidates for GML features, since they have location information. Clearly, the business associate is not. The table of production information is not under GML either - and is probably not a module. Tables are different buggers.

How do I build my three modules and a table to meet the three criteria above?

For example, a side issue is "Feature" vs. "FeatureContainer". A lease contains one or more wells, hence it technically is a container. ...

I disagree. A lease is a legal instrument related to a patch of ground (or water). It may have wells associated with it, but they are not "contained within" it. A better model would be that there is a geometry called a tract (say). The lease has a footprint whose value is the tract. A collection of wells may have a property that they are located on this tract. But I would not make either the tract or lease the container feature. -- SimonCox - 24 Jul 2003

... If I make it so, the slot for the well becomes a Feature. But this does not allow me to plug in a general module for a well. The thing I plug in must be a well, which is an extension of a gml:Feature. So I am probably forced to make the lease and the well as Features, with a modular slot in the lease module to accept a well module that may or may not be a feature.

  1. GML (and thus XMML) properties may point to their value by reference, using a xlink:href, as an alternative to representing the value in line. This allows you to point to any other object, which does not have to be expressed in GML.
  2. however, there is no prohibition to defining a property of a GML or XMML feature to have a content model defined by schemas from a different namespace. For example, we are looking at the Record element defined in xCIL.xsd as a general solution to recording "contact" or "responsible party" information.

-- SimonCox - 24 Jul 2003

Another issue, which I have no reply from yet, is that I may be getting a lease and a well from different namespaces. Consider, for example, that I grab a lease from some group that has used GML 3.0.1. Then I grab a well from another spot that has used GML 3.1 (I'm looking to the future a bit). Both of these have built their modules on top of different versions of GML. When I combine them into a single application schema, will I have problems importing from GML 3.0.1 and GML 3.1? Will they have the same namespace? Will they be compatible? Will the XML instance documents need to have multiple GML namespaces?

-- JohnBobbitt - 22 Jul 2003

Major versions of GML are intended to be fully compatible. But I'm sure there will be wrinkles ... -- SimonCox - 24 Jul 2003
Topic revision: r19 - 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).