Context Navigation

Changes between Version 7 and Version 8 of FdoEnhancedSchemaNameSupport

Timestamp:: 10/18/07 15:05:02 (17 years ago)
Author:: gregboone
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

FdoEnhancedSchemaNameSupport

-              v7
+              v8
         • 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:
+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
 …
         • Qualified Schema Element name compatibility. This option changes the rules for constructing qualified element names. In pre-slate, double quotes are always literals but in Slate they would be delimiters. It is unlikely that any pre-existing schema names start and end with a double quote but it is possible.
         • GML Schema names no longer guaranteed to follow the http scheme. Almost every GML schema we've seen sofar follows this URI naming scheme, so customers might complain if we don't always follow it. Therefore, this option does not work well for the Publish as WFS use case. Clients doing this sort of publishing will likely start specifying FdoXmlFlags to WriteXml to ensure that the GML Schema name follows the http scheme.
+        • GML Schema names no longer guaranteed to follow the http scheme. Almost every GML schema we've seen sofar follows this URI naming scheme, so customers might complain if we don't always follow it. Therefore, this option does not work well for the Publish as WFS use case. Clients doing this sort of publishing will likely start specifying !FdoXmlFlags to !WriteXml to ensure that the GML Schema name follows the http scheme.
 Conclusions:
 …
 Cons:
         • More complicated API. Client must create set of override classes, instead of just setting the schema name attributes or FdoXmlFlags.
+        • 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.
 …
 Currently, FdoFeatureSchemaCollection is the highest level schema object. Under this option FdoSchemaNamespaceCollection would become the highest level object.
+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.
 …
 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.
+        • 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.
 …
         • 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.
+        • 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.
 …
         • This option is viable but not recommended. The main reasons are:
                 o it departs from the OpenGeospatial schema model
+                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:
+Under this option, namespace would not be a fully fledged Fdo Schema Element but merely a new attribute on !FdoFeatureSchema:
 {{{
 …
 }}}
 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:
+!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:
 …
 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.
+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.
 …
 Pros:
         • introduces a bit less complexity to the FDO Schema model in that there is no new FdoSchemaNamespace class.
+        • 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.
+        • 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.
+        • 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.