Changes between Version 5 and Version 6 of FdoEnhancedSchemaNameSupport

Timestamp:

10/18/07 14:55:22 (17 years ago)

Author:

gregboone

Comment:

--

FdoEnhancedSchemaNameSupport

@@ -263 +263 @@
 
         • Despite the overlap with GML schema overrides, this would currently be the recommended option, since it is the best one mentioned in this document. 
+
+==== Schema Overrides ====
+
+The !FdoXmlSchemaMapping class already provides a way to match FDO and GML names for each feature schema. This is provided by this class' name (FDO name) and targetNamespace (GML name) settings. This class can already be passed to !ReadXml() and !WriteXml() via the !FdoXmlFlags. We'd just need to start using its mappings in !ReadXml() and !WriteXml(). 
+
+Pros:
+
+        • Flexible. The GML and FDO schema name correspondences can be set on a per-schema basis.
+
+        • More consistent with rest of FDO since GML names specified as GML-specific overrides.
+
+        • Opens up the ability to specify overrides for other FDO schema elements and customize how they are translated to GML. This would allow us to round trip other GML and XML Schema constructs, that don't easily fit into FDO, such as xs:choice elements.
+
+Cons:
+
+        • More complicated API. Client must create set of override classes, instead of just setting the schema name attributes or FdoXmlFlags.
+
+        • Problematic for Schema Exchange use case. Instead of ensuring consistent url prefixes are used by both !ReadXml() and !WriteXML(), the customer must ensure that consistent GML Schema Overrides are used. Instead of having to manage names, they have to manage object hierarchies or XML fragments.
+
+        • Problematic for Publish as WFS use case. The GML Schema Overrides must be persisted somehow so that consistent GML schema names are used, each time someone retrieves schemas from the WFS. Currently, they must be persisted in some file storage location. 
+
+One way to mitigate this con is the allow them to be stored in the provider datastore if the provider supports FdoIApplySchema. The RDBMS provider implementations of this command can take a set of schema overrides. However, they discard all overrides except those for that particular provider. A possible enhancement would be for the RDBMS providers to be able to persist schema overrides from other providers. This could be done by adding a CLOB column to f_schemainfo, where these overrides would be stored in XML format. There is a problem with doing this in that Schema Overrides cannot be serialized to XML without their corresponding provider being present, which is not guaranteed. Perhaps this enhancement should be limited to just handling GML Schema Overrides. These overrides can be serialized using only core FDO. 
+
+Conclusions:
+
+        • This is the most elegant solution but it lacks the simplicity of the Schema Name Attributes option:
+                o it requires the use of Schema Overrides, which are not popular with application developers.
+                o the persistence problems are worse. Instead of needing to persist a name, a whole set of classes or an XML fragment must be persisted.
+