The OGC is updating GML 3.2 to make use of the current XLink 1.1 standard from the W3C (instead of 1.0 as currently used). What is this going to mean for GML users? The answer depends on how you work with the schemas.

First of all, here is a quick summary of the changes:

  1. The XLink schema has been reorganised internally, but the data structures it defines are unchanged (at least as far as their use in GML is concerned).
  2. The GML schemas will be changed so that the “schemaLocation” hints in their import statements refer to the new XLink 1.1 schemas hosted by W3C instead of the copy of the XLink 1.0 schemas stored on the OGC website.
  3. Application schemas that import the XLink schemas also need to change their import statements to reference the new XLink 1.1 schemas.

Reading GML data

What change will I see in GML 3.2 data? None at all!

The schemas which define the data structure have been reorganised but they still define the same structure. GML data which validates against the XLink 1.0 schema will still validate against the XLink 1.1 schemas. As a GML data user you will probably never even know (or care) which version of the schemas you are using.

Creating GML data

If you are creating data you probably don’t need to do anything different either. If you do include the XLink schema files in your “schemaLocation” hint in the data you should update to the new location – schemaLocation=”http://www.w3.org/1999/xlink http://www.w3.org/XML/2008/06/xlink.xsd”. Including the XLink schemas in your schemaLocation is not stricly necessary so you could simply rely on the schema location settings imported from the schema files. However, some schema validation engines like to have a file location specified in the XML data for all namespaces, so you might want to include it to be on the safe side.

Developing GML application schemas

If you are a developer of GML application schemas then you will need to start referring to the new XLink schemas within your application schemas. This is very simple to do. The XML namespace has not changed, and although some of the internal organisation of the XLink schemas has changed, the data structures defined in it are the same as before. All you have to do is use the W3C file location in your schemaLocations like this…

<xs:import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.w3.org/XML/2008/06/xlink.xsd"/>

A curious feature of the “schemaLocation” attribute in XML is that it is a hint, not a hard and fast rule about where software should go to find the definitions in the imported namespace. This means that implementers of software are free to ignore the hint and get the schemas from wherever they like. For example, an application could choose to read a local copy of the schema file instead of one hosted on the internet.

Where things can get messy is where an application finds two different “schemaLocation” values for the same namespace. For example, XML Spy will read both copies of the schema file and then complain that some tags are defined twice. This is a perfectly reasonable complaint since the schemas are pointing to two (possibly contradictory) versions of the schema file. This is why it is important, if you are developing a schema, to try and keep the references to XLink from your schemas consistent with the ones in the GML schemas you import.

Snowflake’s applications take a more tolerant approach to “schemaLocations” than many applications. Our applications will use the “schemaLocation” to find a schema file, but if a file of that name has already been read for that namespace they will not re-read the file. In effect, when the application encounters a schema file for the second time it says “I have already seen that one, so I won’t read it again”. This approach is tolerant of mixed references to local and on-line copies of the schema file.

How does this policy work when we come to the XLink upgrade? If you have a mixture of XLink 1.0 and XLink 1.1 references in your schemaLocations Snowflake’s applications will simply read the version they encounter first. However, since the data structure defined in the two versions are the same you will not notice any difference.