"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"
The following issues are parked in the "future" space for the stated reasons:

GML3 support

It is a given that GML3 will need to be supported, however currently the WFS spec and the underlying Geoservewr reference implemtation only supports GML2. Having looked into this is not a trivial change, and its one I think we can safely park, and reasonably expect the open source community to eventually solve it for us. There does not appear to be a functional limitation inherent in using GML2 syntax for the demonstrator.

That said:
  • Stylesheets etc should be developed agnostic re GML2 or 3 syntax. If a generic process to convert GML2 to GML3 is required we can implement this at the client side.
  • WebMap Composer functions are agnostic already, although further testing is required.
  • There is probably a case to be made to allow a single logical feature type to have mutliple equivalent schema representations - this would also relate to the issue of multiple query schemas delivering the same output object.

Multiple query patterns delivering the same feature type

This cant be done neatly within the WFS semantics - without an extra framework for declaring that the multiple advertised feature types (1 per query strategy) are implementations of the same logical feature type.

For further discussion.

Object complexity

The current project reference implementation makes a huge leap forward in terms of being able to deliver real world queries against complex database schemas and deliver output according to community schemas. It does however have limited support for object complexity.

Objects may, essentially, follow a master/detail pattern, where a single multi-valued property contains the "detail" records. This property must be allowed by the schema to be the last property in the serialised (XML) object.

This capability allows a whole new class of applications to be built, but GML itself allows objects to be related as an arbitrary graph of related objects, and this will take significant effort to be able to develop a customisable way of defining, efficiently querying, outputting and parsing at the client side.

Discussions with the geoserver and geotools community is underway regarding the design of a capability to define "joins' between data stores. The Deegree WFS implementation has also been thinking along these lines it turns out.

-- RobAtkinson - 21 Oct 2004

All XML documents are trees. The links required to build trees can only be made using out-of-band links (e.g. using xlink:href). However, if these are denormalised and shown inline, then the structure is a tree. Note that, since the value of each ID attribute must be unique within a document, when multiple uses of the same object are made by copying the value inline, it is actually no longer the same object - the ID's must be different.

Thus a GML Feature (and other GML objects such as definitions) is instantiated as a tree, not a graph. The union of the feature-types of interest within a domain generally compose a graph, but each feature-type only samples a subset of the graph that corresponds to a tree. If the complete model is expressed as a UML class diagram graph, then to instantiate a feature you must first stand on one of the classes and then only instantiate objects corresponding to classes linked outwards from that point.

-- SimonCox - 24 Oct 2004
Topic revision: r4 - 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).