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
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:Beziercurve segments in the geometries of WOML line and surface objects. Previously only
gml:LineStringSegmentwere 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
MeteorologicalAnalysismay 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:
List of all the issues resolved in these releases:
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!