Blog

Blog from April, 2011

A "bug fix" for the latest WOML Core was released today. The only issue fixed in this update is WOML-44. There was on error in defining ReferenceableObjectArrayAssociationType used as type of sharedObjects property in WOML collection types. The intention of this element is to contain any number of identifiable GML objects referenced by more than one element inside the WOML collection. When the same objects (like locations, parameter definitions, valid times etc.) are needed several times within one collection, they can be included only once in the sharedObjects and referenced using xlink:href attributes from other elements.

The ReferenceableObjectArrayAssociationType was defined in the following way:

Schema version 1.0
<complexType name="ReferenceableObjectArrayAssociationType">
  <sequence>
     <element name="member" type="gml:AbstractGMLType" minOccurs="0" maxOccurs="unbounded" />
  </sequence>
</complexType>

This did not work as intended however, because the "member" element could only be substituted with elements having that particular element as their substitutionGroup attribute (there were no such elements defined in WOML schemas). The correct formulation for this schema type is :

Schema version 1.1
<complexType name="ReferenceableObjectArrayAssociationType">
  <sequence>
     <element ref="gml:AbstractGML" minOccurs="0" maxOccurs="unbounded" />
  </sequence>
</complexType>

Now we can use any element having gml:AbstractGML element as their substitutionGroup as the content of elements of this type.

This change was rolled out as a minor update of WOML Core version 2011/03/15, identified by schema "version" attribute value 1.1. This means that the old schema version 1.0 was overwritten with the updated version in the schema file directory. The schema documentation for all the WOML modules was also updated to reflect the change.

Sorry for any inconvenience.

Yesterday we managed make the release versions "2011/03/15" of all four WOML modules (Core, SWO, Quantity and Textfct). This version contains some major changes in the schemas, including upgrade to GML 3.2, abandoning the interpolated versions of the curve geometries and introduction of data "time series" feature types. It was decided that it would be a good thing to combine these changes, which we know means some changes in the application code, with the move from GML 3.1 to GML 3.2. GML 3.2 schema is pretty different from the 3.1 version, contains a lot more types and elements, and uses them from several other namespaces, like the ISO/TC211 metadata and data quality (http://www.isotc211.org/2005/gmd). For this reason application developers should reserve some time to add support for this new WOML version.

For the ones interested in the history of WOML, the predecessor of WOML, FMI Meteorological Objects schema, was already upgraded to used GML 3.2 once with it's version 2009/09/07 released in September 2009. Due to the (assumed) incompatibility of GML 3.2. with WFS 1.1, this change was reverted in the next release. Now finally after 2.5 years we are bold enough to go for it again (smile)

Some highlights of the changes:

  • WOML 2011/03/15 is based on GML 3.2.1. The previous versions were based on GML 3.1.1. OGC Web Feature Service (WFS) 1.1.1 only mandates that if the requested return format is GML 3.1, the response features must be a GML 3.1 FeatureCollection. If the requested return format is something else (like GML 3.2), the return encoding does not have to use GML 3.1. Thus the spec does not force the use of the older GML version with WFS 1.1.
  • The optional interpolated versions of the primary geometries of line and surface objects are now removed entirely, because of the added complexity with little real benefit to the using applications. See a previous blog post for more discussion on this issue.
  • It is now possible to use gml:Bezier curve segments in the geometries of WOML line and surface objects. Previously only gml:CubicSpline and gml:LineStringSegment were supported. Note: Please tell us what you think of this change? Should we continue to support both Cubic Spline and Bezier curve segments in future versions? Which curve segment types would you prefer?
  • WOML collection types (like WeatherForecast and MeteorologicalAnalysis may now only contain other WOML features. In previous versions the collection extended the the (now deprecated) gml:AbstractFeatureCollection. The reason behind this change is to simplify the job of the applications parsing WOML data: They now better what to expect to find inside the WOML collections. The downside is the decreased flexibility if WOML collections: You can no longer mix features from other schemas with the WOML features inside a WOML collection.
  • Updated and improved documentation in the WOML Wiki:
    • All the UML diagrams have been updated to match the changes in the new version.
    • UML class diagram has been added to Textfct page.
    • A Usage examples page has been added to WOML Wiki. Ask for more XML examples to be included if you require them.

List of all the issues resolved in these releases:

Key Component/s P Summary Status
Loading...
Refresh

Please note that if you use Apache XMLBeans for generating XML-to-Java mappings for WOML, the amount of generated classes (an the file size of their jar) has increased considerably: For example the size of the jar file containing the generated class files for WOML Core was about 3.9 MB in version 2010/11/15, and it's about 10.4 MB in this version. This is caused directly by the increased amount of the types and elements in the GML 3.2 and referred XML schemas compared to GML 3.1. It also takes considerable CPU resources to generate, build and especially javadoc this many classes (4905 generated class files currently from WOML Core), so you should probably consider using tools that can skip generating Java classes not needed for your WOML usage. If you find good alternatives to XMLBeans, feel free to add a comment or send me email.

We also have some very interesting discussions going on about international co-operation in WOML development and possibilities of introduction of WOML into the OGC Interoperability Experiments and standardization process. More details on this to be revealed in later posts.

As always, please give any feedback and keep sending improvement requests, currently there aren't many in the queue, so your's might get implemented sooner than you think!