Notice and FAQ regarding transition from the OGC XLink schema to the W3C XLink 1.1 schema
On July 21, the OGC is changing the XLink schema reference (namespace) to the W3C XLink schema. This change is for all OGC standards that reference the OGC XLink schema. Therefore, developers of implementations that reference the affected schemas will need to make small code changes in order to enable an orderly transition to the use of the W3C XLink schema. This change will better align OGC standards with both current W3C Recommendations and broad community practices, thus improving application interoperability for our many members and their customers.
There is a complete set of beta schemas available:
And there is an email list for discussion:
REPORTING ISSUES: Please make sure that you are subscribed to the email list. IF you encounter any issues or have questions regarding the transition, please post a message to the above list!! The OGC will be monitoring this list closely over the next few weeks. Thanks
The policy decision and technical fixes are explained in my April 24, 2012 OGC Blog post (http://www.opengeospatial.org/blog/1597). More information is available in the FAQ is below.
There have been announcements and blog postings for 6 months, yet apparently many organizations are only now beginning to look at the impacts on their software etc. Please have your developers look at the implications of this change!
The key issue is that schema parsers become confused (fail) when schemas with the same XML namespace are loaded.
OGC Member organizations that have made the necessary changes and tested their implementations against the beta schemas report that making the change was a relatively straightforward task and that no issues with the transition from the current schema-set to the new schema-set were encountered. Further, GML instance documents are not affected.
We encourage you to take the necessary steps with your software and applications, and we ask that you do whatever you can to help raise awareness among those who might be affected by the XLink issue.
OGC Technical Committee Chair
XLINK FAQ Contents:
- What is XLink
- Why does the OGC have their own XLink schema?
- Why is the switch to the W3C XLink schema necessary?
- When did the OGC decide to make the transition?
- What was the actual motion?
- When will the transition occur?
- Are there beta schemas for testing?
- Are there any other schema changes that are part of the XLink transition?
- Why not generate major version numbers?
- Have other groups been notified?
- What are some good references?
- What exactly is the change?
- What happens if our OGC schemas are not modified?
- Are Instance Documents Impacted?
- What are the use cases?
- My application resides behind a firewall, so what should I do?
- My application uses a local copy of OGC schema. Do I need to make any changes?
- XLink Attribute Guidance
- The XLink transition and gml.xsd - do I need to make changes? 5
What is XLink
XLink is a widely used W3C standard for creating links between XML documents or fragments inside those documents, similar to HTML a tag.
Why does the OGC have their own XLink schema?
Back in 2000, the OGC Members determined that the W3C XLink1.0 recommendation was well suited to the requirements for GML 2.0 as well as other OGC standards. However, in 2000, W3C did not have aXLink schema. Therefore, the OGC Members decided to define an OGC XLink schema that was based on the W3C XLink recommendation. This XLink schema is now used in numerous OGC standards.
Why is the switch to the W3C XLink schema necessary?
Recently, the W3C finally published the XLink 1.1 schema. Further, a number of government procurement organizations have mandated the use of W3C XLink 1.1. Therefore, the OGC needs to transition from the OGC XLink 1.0 schemas to the W3C XLink 1.1 schemas. In concert with the W3C providing a normative XLink schema, the US Government implemented a standards policy statement mandating the use of the W3C XLink schema. For these two reasons, the OGC Membership has determined that transitioning to the new W3C XLink schema is the correct approach.
When did the OGC decide to make the transition?
Discussions about the use of the W3C XLink schema began in early 2011 as part of the OGC GML 3.3 standards revision activity. The GML SWG brought the issue to the attention of the OGC Architecture Board in mid-2011. After a number of discussions, the OAB brought guidance to the OGC Membership. Based on the OAB input, at the December 2011 (Brussels) OGC face to face meetings, the OGC Members approved the recommendation to transition to the W3C XLink schema.
What was the actual motion?
The OGC shall follow the XLink guidance as defined in the W3C XLink 1.1 recommendation: http://www.w3.org/TR/xlink11/ .
The motion further stated that 1.) all existing OGC standards that reference the OGC XLink shall be updated to reference the W3C XLink schema and 2.) that going forward any new standards work shall only reference the W3C XLink schema. At the same time, there is also a related XLink schema change so that simpleAttrs is used.
When will the transition occur?
Are there beta schemas for testing?
Yes. The beta schema to be used in testing may be found at:
Also once the final schema are released on 21 July 2012, they may be
The later should be used to replace any local OGC schema.
Are there any other schema changes that are part of the XLink transition?
The schema are also be modified to incorporate the changes described in
From that document:
"All 'leaf' documents describing part of an XML namespace shall explicitly the 'all-components' schema document. In this way use of any schema document will automatically result in all-components being imported."
Also version numbers will be increased based on guidance defined in the policy document 06-135r11 (OGC Standards Directives)
Why not generate major version numbers?
Yes, the schema change is not backwards compatible. However, the OGC Members decided that this transition is actually a bug fix and as such should be treated as corrigenda - which are also not backwards compatible. Changing the major version number of an OGC standard would generate more issues and confusion than the current approach for the schema transition.
Have other groups been notified?
Yes. Numerous other groups, such as OSGeo, the OGC LinkedIn Group, and ISO TC 211 have been notified of the plan to transition to the W3C XLink schema. More outreach will occur.
What are some good references?
There are some excellent blogs available. This FAQ draws from these blogs as well as other sources.
Background and general:
http://test.snowflakesoftware.com/tag/ogc/ (GML specific)
http://osgeo-org.1560.n6.nabble.com/GML-backwards-incompatible-XLink-changes-go-live-on-21-July-2012-td4982871.html (GML specific)
These blog postings date back to March, 2012.
What exactly is the change?
Schema documents (not instance documents!) will need to change the schema location reference from
xlink:simpleLink will need to be changed to xlink: simpleAttrs
What happens if our OGC schemas are not modified?
The parser may fail/throw an exception/generate an error and the application may stop operation. More specifically, if your software is using XML documents referring to the same versions of XML Schema for the same namespace but their location URL is different, you are heading for trouble.
Are Instance Documents Impacted?
Instance documents do not need to be changed. Only implementations that reference schema location need to be changed.
What are the use cases?
There are several use cases that will cause a schema parser to fail. All of the use cases relate what happens when a parser loads the XLink schema from one location - whether the OGC site or a local copy - and then at a future time tries to load the XLink schema from the W3C schema repository.
- An application schema references GML as well as other schema. The application schema references the W3C XLink schema. Current GML references the OGC XLink schema. This will cause a schema collision with possible consequences - such as validation failure.
- Your software/application is operational inside the corporate firewall. You are referencing a local copy of OGC schema - including the OGC XLink schema. At some point, your software/application accesses OASIS CIQ schema that references the W3C XLink schema.This will cause a schema collision with possible consequences - such as validation failure.
- Your software/application that implements OGC standards is operational inside the firewall but access data and services outside the corporate firewall. At some point, your software/application accesses a service outside the firewall that in turn references the OGC schema repository that uses the W3C XLink schema.This will cause a schema collision with possible consequences - such as validation failure.
My application resides behind a firewall, so what should I do?
If your application is hidden behind a firewall, there may be some issues. They could download the currently available changed schemas, but must do so in their entirety so that you are not mixing old and new. There is also the possibility of using the OASIS Catalogue. This allows you to remap where an XML parser looks for schema:
An example of an OASIS Catalog is at http://beta.schemas.opengis.net/catalog.xml
My application uses a local copy of OGC schema. Do I need to make any changes?
If you are 100 (or 110%) sure that your application will NEVER reference any other schema than the local copy and you are sure that other referenced schema NEVER accesses the W3C XLink schema, then no changes are necessary. However, we would still encourage these groups to use the updated schema, replace your local copies, and run some testing. That way, you are guaranteed that at some future time your application will not have schema conflicts.
XLink Attribute Guidance
Both the OGC and the W3C XLink XML Schema implement the XLink Attribute
Usage Patterns defined in 4.1 of http://www.w3.org/TR/xlink11/ through
XML Shema attribute groups, but with different names. The use of those
attribute groups is consequently recommended.
For instance, where a data instance has an element that serves as an XLink, then if there is no xlink:type attribute the default is a "simple" xlink, and an xlink:href attribute must be present. The OGC Architecture Board (OAB) is not aware of any OGC standard that specifies any type of xlink other than "simple". The W3C XLink 1.1 Recommendation specifies in section 4.1 that for a simple XLink either xlink:href or xlink:type must be present. The OAB suggests we use xlink:href for any simple XLink.
The XLink transition and gml.xsd - do I need to make changes?
Yes the GML gmlBase.xsd will have to change:
<attributeGroup name="AssociationAttributeGroup"> <annotation> <documentation>
The attribute group is used to enable property elements to refer to their value remotely. It contains the simple link components from xlinks.xsd, with all members optional, and the remoteSchema attribute, which is also optional. These attributes can be attached to any element, thus allowing it to act as a pointer. The 'remoteSchema' attribute allows an element that carries link attributes to indicate that the element is declared in a remote schema rather than by the schema that constrains the current document instance.
</documentation> </annotation> <attributeGroup ref="xlink:simpleLink"/> <attribute ref="gml:remoteSchema" use="optional"/> </attributeGroup>
must change as well as changing the schema location. So whenever a GML application schema fetches the new OGC XML schema with the new attribute group name in it, the application must also fetch the xlink.xsd from the W3C server - otherwise the XML instance breaks.