Changes between Version 1 and Version 2 of FdoEnhancedSchemaNameSupport


Ignore:
Timestamp:
Oct 18, 2007, 2:30:51 PM (17 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FdoEnhancedSchemaNameSupport

    v1 v2  
     1
     2== !!!!! NOTE: UNDER CONSTRUCTION ==
    13
    24== FDO Enhanced Schema Name Support ==
    … …  
    810The 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:
    911
    10 ''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.
     12• 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.
    1113
    12 ''Schema Exchange'': Allow exchange of schemas between FDO and external GML-based applications.
     14• Schema Exchange: Allow exchange of schemas between FDO and external GML-based applications.
    1315
    14 ''WFS Provider'': used by the FDO WFS Provider to translated GML schemas, provided by the connected WFS, to FDO Schemas.
     16• WFS Provider: used by the FDO WFS Provider to translated GML schemas, provided by the connected WFS, to FDO Schemas.
    1517
    16 ''Publish as WFS'': Allow FDO accessible data to be published via a WFS. This is the opposite of the previous use case.
     18• Publish as WFS: Allow FDO accessible data to be published via a WFS. This is the opposite of the previous use case.
    1719
    1820One 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:
    1921
    20 • 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.[[br]]
     22• 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.
     23
    2124• 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.
    2225
    2326The structure of schema names differs greatly in either format:
    2427
    25 • 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.[[br]]
     28• 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.
     29
    2630• 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.
    2731
    … …  
    3337
    3438The 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.
     39
     40=== Current API ===
     41
     42Feature Schema translation is provided by 2 functions on !FdoFeatureSchemaCollection:
     43
     44• !ReadXml() converts GML schemas to FDO[[br]]
     45• !WriteXml() converts FDO schemas to GML (!WriteXml() is also present on !FdoFeatureSchema to allow the writing of individual schemas).
     46
     47Both of the above functions take optional !FdoXmlFlags parameters, which control how the translation is performed.
     48
     49The following sub-sections look at the various schema name translation options currently provided:
     50
     51==== Default Translation ====
     52
     53===== FDO to GML =====
     54
     55When 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:
     56
     57http://fdo.osgeo.org.schemas/feature/Water-x20-Service
     58
     59===== GML to FDO =====
     60
     61When 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:
     62
     63http://www.mycity.on.ca/departments/transportation/Roads
     64
     65becomes:
     66
     67www-dot-mycity-dot-on-dot-ca/departments/transportation/Roads
     68
     69This preserves name uniqueness but leads to a rather messy looking FDO schema name that is not easily human-readable.
     70
     71When 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:
     72
     73http://fdo.osgeo.org/schemas/Roads
     74
     75simply becomes:
     76
     77Roads.
     78
     79This is done to preserve round-trip fidelity.
     80
     81===== Use Case Implications =====
     82
     83====== Export/Import ======
     84
     85The 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.
     86
     87====== Schema Exchange ======
     88
     89The 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.
     90
     91There 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:
     92
     93http://www.mycity.on.ca/departments/transportation/Roads
     94
     95becomes:
     96
     97www-dot-mycity-dot-on-dot-ca/departments/transportation/Roads
     98
     99in FDO. However, when written back to GML, the default prefix is still prepended to the schema name, giving:
     100
     101http: //fdo.osgeo.org/schemas/feature/www.mycity.on.ca/departments/transportation/Roads
     102
     103Therefore, round trip fidelity is not preserved.
     104
     105====== WFS Provider ======
     106
     107The Default method is not applicable to the WFS Provider use case. The WFS Provider always passes FdoXmlFlags to the ReadXml function.
     108
     109====== Publish as WFS ======
     110
     111As 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/.
     112
     113
     114