This page last changed on Oct 04, 2007 by jdeolive.

We obviosly need to be able and retrieve features at a specific revision. In WFS an hook is already available to support versioned request, in particular in the Query element of a GetFeature request:

<xsd:complexType name="QueryType">
  <xsd:attribute name="featureVersion" type="xsd:string" use="optional">
        For systems that implement versioning, the featureVersion
        attribute is used to specify which version of a particular
        feature instance is to be retrieved.  A value of ALL means
        that all versions should be retrieved.  An integer value
        'i', means that the ith version should be retrieve if it
        exists or the most recent version otherwise.

This would make us standard compliant with WFS and limit filtering capabilities to equality, thought we have to implement ALL as well. The documentation explicitly says either ALL or an integer must be used, but we'll be more lenient and support other formats as well:

  • numeric version
  • timestamp (in some ISO standard, locale independent format)
  • branch:version
  • branch:timestamp
  • ALL
  • FIRST (first state committed in a branch)
  • LATEST (head of a branch).
    This does not pose validation issues, since version attribute is a generic "string". LATEST should become the default value for Query featureVersion attribute, that is, if not specified, the server acts as if the latest version is required.

Returned feature collections should provide a version number, so that clients can build a checkout and just ask for differences in subsequent requests. This can be done by extending FeatureCollection into a VersionedFeatureCollection, being part of the same substitution group as FeatureCollection, which reports the last version for each feature type (given that some feature types may not be versioned, and others may come from different versioning datastores):

<VersionedFeatureCollection ... >
   <!-- collection made of features coming from feature types ft1, ft2, ft3, 
        ft1 and ft2 coming from different versioning data stores, ft3 being unversioned -->
      <FeatureTypeVersion typeName="ft1" featureVersion="1156"/>
      <FeatureTypeVersion typeName="ft2" featureVersion="1256"/>
      <!-- ft3 not included in this list because -->

Providing version numbers is an optimization that can be added later, since basic versioning functionality is there even without checkouts.

Here we should add an extension of GetFeature that is able to return features modified by a specific user

Document generated by Confluence on May 14, 2014 23:00