Version 3 (modified by 17 years ago) ( diff ) | ,
---|
!!!!! NOTE: UNDER CONSTRUCTION
FDO Enhanced Schema Name Support
Overview
This document discusses various options for improving the translation of Feature Schema names between FDO and GML.
The FDO API provides functions for translating FDO Feature Schemas to and from the OpenGeospatial GML format. These functions are provided to satisfy 4 main use cases:
- Export/Import: to provide a text based export format for FDO Feature Schemas. This export format actually covers other types of objects such as Spatial Contexts, Schema Overrides and Features. However, only Feature Schemas are pertinent to this document.
- Schema Exchange: Allow exchange of schemas between FDO and external GML-based applications.
- WFS Provider: used by the FDO WFS Provider to translated GML schemas, provided by the connected WFS, to FDO Schemas.
- Publish as WFS: Allow FDO accessible data to be published via a WFS. This is the opposite of the previous use case.
One of the big challenges, in translating schemas between FDO and GML, is the converting of schema names. In order to support the above use cases, these conversions must satisfy the following general requirements:
- round trip fidelity. If the schema is translated from GML to FDO to GML, the schema name in the resulting GML schema document must be the same as in the original. Similarly, the name must not change when translated from FDO to GML to FDO.
- name uniqueness must be preserved. Different GML schemas must get different FDO schema names when read into FDO. Conversely different FDO schemas must get different GML schema names when written to GML. If name uniqueness is not preserved, schemas will be unexpectedly merged on read or write.
The structure of schema names differs greatly in either format:
- in FDO, a schema name is a free-form name, containing any character except '.' and ':'. Names tend to be short; more detailed information is typically kept in the schema description.
- in GML, the schema name must be a valid URI. Most current FDO schema names are valid URI's. However, most GML schema names tend to conform to the http scheme (see glossary), as seen in the following example. FDO Schema names would tend to not fit the http scheme.
A typical example might be a Roads schema defined by the municipality "MyCity". The FDO schema might simply be "Roads". However, the GML schema name might look something like this:
http://www.mycity.on.ca/departments/transportation/Roads
where the schema name is qualified by the owning organization. This makes it difficult to perform the schema name conversion in a way that satisfies the abovementioned requirements.
The FDO API provides a number of methods to ensure round trip fidelity and preservation of schema name uniqueness. However, these methods are cumbersome for some of the abovementioned use cases. This document looks at alternatives for making schema name translation easier when performed through the FDO API.
Current API
Feature Schema translation is provided by 2 functions on FdoFeatureSchemaCollection:
- ReadXml() converts GML schemas to FDO
- WriteXml() converts FDO schemas to GML (WriteXml() is also present on FdoFeatureSchema to allow the writing of individual schemas).
Both of the above functions take optional FdoXmlFlags parameters, which control how the translation is performed.
The following sub-sections look at the various schema name translation options currently provided:
Default Translation
FDO to GML
When no FdoXmlFlags are specified, the FDO schema name is translated by prepending a default osgeo-defined schema prefix (http://fdo.osgeo.org/schemas/feature/) to the schema name and escaping any characters not allowed in a URI. For example, the FDO Schema "Water Service" becomes:
http://fdo.osgeo.org.schemas/feature/Water-x20-Service
GML to FDO
When no FdoXmlFlags are specified, GML schema names are translated by dropping any http:// prefix and escaping '.' and ':' to '-dot-' and '-colon-' respectively. This means that the example schema name from the Overview:
http://www.mycity.on.ca/departments/transportation/Roads
becomes:
www-dot-mycity-dot-on-dot-ca/departments/transportation/Roads
This preserves name uniqueness but leads to a rather messy looking FDO schema name that is not easily human-readable.
When the GML schema name begins with the default schema prefix (http://fdo.osgeo.org/schemas/feature/), this whole prefix is removed from the schema name. For example:
http://fdo.osgeo.org/schemas/Roads
simply becomes:
Roads.
This is done to preserve round-trip fidelity.
Use Case Implications
Export/Import
The Default method works well for the Export/Import use case. The schema name is preserved on round trip from FDO to GML to FDO. The http://fdo.osgeo.org/schemas/feature/ prefix is added when the feature schemas are written to GML and removed when they are read back from GML. The fact that the GML schemas all look like they're owned by OSGeo is not an issue. Actors, for this use case, aren't concerned about the GML format itself; they just want to be able to export FDO schemas and re-import them later.
Schema Exchange
The Default method does not work well for the Schema Exchange use case, since it generates rather messy FDO schema names from the GML names. Also, when FDO schemas are written to GML, the schema name always gets the default prefix prepended. Most customers would likely want the GML schema name to be a URI that reflects their own organization, rather than OSGeo.
There is also a defect which occurs when a schema name, that doesn't start with the default prefix, is round tripped from GML to FDO to GML. The GML Schema name:
http://www.mycity.on.ca/departments/transportation/Roads
becomes:
www-dot-mycity-dot-on-dot-ca/departments/transportation/Roads
in FDO. However, when written back to GML, the default prefix is still prepended to the schema name, giving:
http: fdo.osgeo.org/schemas/feature/www.mycity.on.ca/departments/transportation/Roads
Therefore, round trip fidelity is not preserved.
WFS Provider
The Default method is not applicable to the WFS Provider use case. The WFS Provider always passes FdoXmlFlags to the ReadXml function.
Publish as WFS
As with the Schema Exchange use case, the default method does not work well for the Publish as WFS use case since all schema names end up prefixed with http://fdo.osgeo.org/schemas/feature/.