OGC Xlink Policy and timeline to move to XLink 1.1

Post date: 
23 April 2012
Tags: 
OGC, standards, ogcdoc, xlink

Back in 2000, the OGC Members determined that the W3C XLink recommendation was well suited to the requirements for GML 2.0 as well as other OGC standards. However, at that time, W3C did not have a XLink 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 (See below).

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. This sounds an easy enough transition. In reality, this is a major change and will break any application using OGC standards that reference XLink unless the application also transitions to the W3C XLink 1.1 schema.

At the 2011 Brussels meeting, the TC and the PC approved a motion that:

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.

Specifically:

http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd will be changed to http://www.w3.org/1999/xlink.xsd and

xlink:simpleLink will be changed to xlink: simpleAttrs )

The target date for implementing change is the weekend of July 21, 2012.

The process will be:

1. Scan schema repository for import of xlink to find a list of standards that use xlink.

2. Also scan for strings such as Gml:ReferenceType to find other possible places that xlink is required.

3. Whatever schema uses any of XLink schema components will need to replace the schema location. We need to do this for all schemas that import xlink. All these changes will be done to a copy of the existing OGC schema repository.

4. Create a copy of the OGC schema repository and announce this location so that product developers can test their implementations of affected OGC standards against this beta version of the OGC standards.

5. For software developers, they need to patch their products to use the revised OGC schemas.

6. Everyone will need to delete local copies, get a new copy from the OGC schema repository, and use the new schemas. There is also the possibility to use a tool such as the OASIS XML Catalogue to override the required change and to continue using the old XLink.

7. In July, we will then issue one global corrigendum for all the affected standards. Essentially, the current OGC schema repository will be replaced with the schemas that have been changed (and tested)The actual standards documents will not change – only the schemas. OGC policy is that the schemas are normative and that if there are differences between a standards document and a schema, then the schemas are normative.

Concurrently, we need aggressive OUTREACH, OUTREACH, OUTREACH to inform and educate the implementation and user community. For example, we need to:

  • Coordinate with TC 211
  • Coordinate with OASIS
  • Coordinate with the GeoSciML community
  • Coordinate with INSPIRE
  • Inform all technology developers that they need to check their offerings and determine what (if any) changes they need to make. Not just OGC Members but the whole community!
  • Coordinate with the Open Source community also
  • Use LinkedIn, Blogs, and other social media.

Below is a preliminary list of the OGC standards (and versions) impacted by this change

  • All versions of WM context
  • All versions of GML since version 2.0.0
  • All profiles of GML since 2.0.0
  • Image CRSs
  • All versions of OpenLS since version 1.1.0
  • All versions of OWS Common since 1.0.0
  • Symbology Encoding 1.0
  • All versions of SLD since 1.0.0
  • All versions of SensorML (including 2.0)
  • All versions of SWE Common
  • Table Join Service
  • All versions of Web Coverage Service
  • Web Feature Service 2.0
  • Web Map Service 1.3
  • WMTS
  • Web Processing Service

Comments

Webmaster's picture

Webmaster

Thursday, 2012-06-21

In order to manage issues and comments related to the publishing of the schema changes related to OGC XLink and XLink 1.1, OGC has set up a Public email reflector.

To subscribe to the OGC Beta-Schemas List, go to:  
https://lists.opengeospatial.org/mailman/listinfo/beta-schemas

You may download and test the beta schemas from:  
http://beta.schemas.opengis.net/BETA_SCHEMAS_OPENGIS_NET.zip

EDIT: 2012-07-09
A Notice and FAQ regarding transition from the OGC XLink schema to the W3C XLink 1.1 schema have been posted as a comment below.
(Note: Originally posted on OGCNetwork node/1829 which is no longer active - Webmaster 2019-04-23)

Webmaster's picture

Webmaster

Friday, 2012-06-22

(Note: Originally posted on OGCNetwork node/1829 which is no longer active - Webmaster 2019-04-23)

 

Notice and FAQ regarding transition from the OGC XLink schema to the W3C XLink 1.1 schema

On July 21, 2012, 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:

–    http://beta.schemas.opengis.net/
–    http://beta.schemas.opengis.net/BETA.SCHEMAS.OPENGIS.NET.zip

And there is an email list for discussion:

https://lists.opengeospatial.org/mailman/listinfo/beta-schemas

Please subscribe!

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.

Carl Reed
OGC Technical Committee Chair

XLINK FAQ Contents:

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?

The transition date, as per the OGC Member guidance, is the night of July 21 (US Central time)

Are there beta schemas for testing?

Yes. The beta schema to be used in testing may be found at:
http://beta.schemas.opengis.net/BETA_SCHEMAS_OPENGIS_NET.zip

Also once the final schema are released on 21 July 2012, they may be downloaded from:
http://schemas.opengis.net/SCHEMAS_OPENGIS_NET.zip

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 OGC 11-025:
https://portal.opengeospatial.org/files/?artifact_id=43125

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) http://portal.opengeospatial.org/files/?artifact_id=40077

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://www.opengeospatial.org/blog/1597 http://www.sdimag.com/20120416710/OGC-Switch-to-W3C-XLink-in-July-2012.html Technical http://www.spatineo.com/2012/01/ogc-w3c-xlink-transition-a-potential-val... http://www.spatineo.com/2012/04/ogc-to-switch-to-wc3-xlink-in-july-2012/ http://test.snowflakesoftware.com/tag/ogc/ (GML specific) http://osgeo-org.1560.n6.nabble.com/GML-backwards-incompatible-XLink-cha... (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 http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd to http://www.w3.org/1999/xlink.xsd andfurther, 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.

  1. 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.
  2. 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.
  3. 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:
https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html

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>

The

<attributeGroup ref="xlink:simpleLink"/>

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.