Changes between Version 6 and Version 7 of FdoEnhancedSchemaNameSupport

Timestamp:

Oct 18, 2007, 3:00:29 PM (17 years ago)

Author:

gregboone

Comment:

--

FdoEnhancedSchemaNameSupport

@@ -292 +292 @@
                 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.
 
+==== Schema Namespace ====
+
+Under this option, the concept of a Schema Namespace would be added to FDO, where Feature Schemas would be grouped into namespaces. The intent of the namespace name would be to contain the name of the organization that owns the schema. This could be a complex path as per the http URI scheme. The Feature Schema name itself would tend to be a simple short name as it is now. 
+
+On !WriteXml:
+
+        The GML schema name would be fdo_ namespace + '/' + fdo_schema_name
+
+On !ReadXml:
+
+        the GML schema name would be  split at last '/'. The left part would  become the FDO namespace, and the right part the schema name. If the GML schema name does not contain'/' then it would become the FDO schema name and the namespace would be the default namespace (see below).
+
+There are a couple of sub-options for representing the namespace in FDO. These are discussed in the following subsections, along with Pros, Cons and Conclusions.
+
+==== Full Object ====
+
+Under this sub-option, the namespace would be a fully fledged Fdo Schema Element. Feature Schemas would be grouped into namespaces. This could be done by adding the following classes:
+
+{{{
+class FdoSchemaNamespace: public FdoSchemaElement
+{
+        FdoSchemaCollection* GetSchemas();
+}
+
+class FdoSchemaNamespaceCollection : public FdoSchemaCollection<FdoSchemaNamespace>
+{
+}
+}}}
+
+
+Currently, FdoFeatureSchemaCollection is the highest level schema object. Under this option FdoSchemaNamespaceCollection would become the highest level object.
+
+The SDF and RDBMS providers would be changed to handle namespaces. For the RDBMS providers, this would likely mean adding a new MetaSchema table. For backward compatibility, we'd need to introduce the concept of a default namespace. Feature Schemas in pre-existing datastores would automatically go under the default namespace. 
+
+For backward compatibility reasons, it would not likely be possible for FdoIDescribeSchema and FdoIApplySchema to handle namespaces. We'd need new commands:
+
+
+{{{
+class FdoIApplyNamespace
+{
+        void SetNamespace( FdoSchemaNamespace* namespace );
+        FdoSchemaNamespace* GetNamespace();
+        void Execute();
+}
+
+Class FdoIDescribeNamespace
+{
+        void SetNamespace( FdoString* namespace );
+        FdoString* GetNamespace();
+
+        FdoSchemaNamespaceCollection* Execute();
+}
+}}}
+
+TBD: Ways to apply and retrieve schema overrides for a namespace or collection of namespaces would also be need to be added.
+
+FdoIApplySchema, FdoIDescribeSchema and FdoIDescribeSchemaMappings are all geared to the idea that the !FdoFeatureSchemaCollection is the highest level object. Therefore, the addition of namespaces would affect these commands. For backward compatibility, the best way to handle these commands would be to restrict them to handling feature schemas in the default namespace. The new commands must be used to access and manipulate schemas in other namespaces. It would be possible to allow FdoIApplySchema to handle schemas from non-default namespaces, since the namespace would be the feature schema's parent. However, it would be inconsistent to allow FdoIApplySchema to handle these schemas if they cannot be retrieved through FdoIDescribeSchema.
+
+Feature Commands would also be impacted since these can take qualified class and property names. These qualified names must be able to contain the namespace name if they are to be unique within a particular FDO datastore. This would mean changes to providers that add support for namespaces. 
+
+Although a new command adds complexity, this could be an opportunity to add incremental schema describing. Currently, when a schema is described, all of its classes and properties are retrieved. There is no command to just list the schemas or just the schemas and classes. This affects performance, since callers to FdoIDescribeSchema always get the entire schema when they might be just interested in part of it. 
+
+The ability to just list certain objects could be provided by an elementLevel attribute on FdoIDescribeNamespace:
+
+        !SetElementLevel ( elementType level )
+        elementType !GetElementLevel()
+
+where elementType is one of (namespace, schema,. class, property, constraint, all). When set, Execute() would only return elements down to that level. To list only the namespaces, set elementType to namespace; to list namespaces, schemas, and classes set elementType to class. Setting elementType to property would cause everything except for unique and property value constraints to be retrieved (this would have performance benefits for RDBMS providers). Setting elementType to all would retrieve everything. 
+
+Pros:
+
+        • More generalized than the Schema Name Attribute approach. Instead of putting a schema override on FdoFeatureSchema, we add a new provider-neutral concept to the Fdo Feature schema model. 
+
+        • Better than the Schema Override approach since a separate Schema Overrides set is not required to customize schema name translation between FDO and GML.
+
+        • Flexible. The GML and FDO schema name correspondences can be set on a per-schema basis.
+
+        • Provides an opportunity to support incremental schema describing
+
+Cons:
+
+        • Existing providers might not immediately add support for namespaces. When these providers are used, it is not possible to persist the GML to FDO schema name correspondences.
+
+        • Schema names themselves no longer unique, unless also qualified by namespace. Some applications might rely on schema names being unique
+
+        • Introduces a whole new level to the Fdo Feature Schema model, adding to its complexity. This isalso a departure from the OpenGeospatial model, where a schema is a namespace, rather than being contained in a namespace. 
+
+        • This option may seem to get rid of the problem where schemas read from GML have long names. However, it merely splits these long names and puts the more complex part in the namespace name. Clients still new need both namespace and schema name to uniquely identify a schema.
+
+Conclusion:
+
+        • This option is viable but not recommended. The main reasons are:
+                o it departs from the OpenGeospatial schema model
+                o it adds complication to the FDO Feature Schema model
+                o the implementation effort is a bit high. 
+
+
+==== Just a Name ====
+
+Under this option, namespace would not be a fully fledged Fdo Schema Element but merely a new attribute on FdoFeatureSchema:
+
+
+{{{
+        class FdoFeatureSchema
+        {
+                void SetNamespace( FdoString* namespace );
+                FdoString* GetNamespace();
+        }
+}}}
+
+
+The Schema name would no longer be unique within FDO Datastore, the combination of namespace and schema name would be unique (Otherwise, this option would be the same as the Schema Name Attributes option). 
+
+FdoFeatureSchemaCollection would be impacted in that it cannot hold schemas of different namespaces since schema names must be unique within each collection. Because of this, FdoIDescribeSchema cannot retrieve all schemas for an FDO datastore if they are in different namespaces. This necessitates adding a new command:
+
+
+{{{
+Class FdoIDescribeNamespace
+{
+        void SetNamespace( FdoString* namespace );
+        FdoString* GetNamespace();
+
+        FdoFeatureSchemaCollection* Execute();
+}
+}}}
+
+
+Note that it is a bit different than the FdoIDescibeNamespace from the previous section, in that it returns an FdoFeatureSchemaCollection. Therefore, this command will only be able to retrieve the schemas for a single namespace. This also means we need an extra command to list all the namespaces on a datastore. 
+
+We'd still need to add namespace to qualified schema element names and modify the feature commands to handle the namespace component.
+
+Compared to other options, this option has the same pros and cons as the Schema Namespace - Full Object sub-option. When compared with Schema Namespace – Full Object, it has the following pros and cons:
+
+Pros:
+
+        • introduces a bit less complexity to the FDO Schema model in that there is no new FdoSchemaNamespace class. 
+
+Cons:
+
+        • less flexible since FdoIDescribeNamespace cannot retrieve schemas for all namespaces. 
+        • an extra command is required to list namespaces, since there is no FdoSchemaNamespaceCollection class. 
+
+Conclusion:
+
+        • Same Conclusions as for Schema Namespace - Full Object. However, eliminating the FdoSchemaNamespace and FdoSchemaNamespaceCollection objects doesn't buy us much so this sub-option is not recommended.
+
+
+=== Open Issues ===
+
+        • Does MapGuide currently support exposing an FDO datastore as a WFS? If so, have they encountered problems generating the targetNamespace for each schema? If not currently supported, do they plan to support Publish as WFS in the future.
+