Changes between Version 7 and Version 8 of FdoEnhancedSchemaNameSupport


Ignore:
Timestamp:
Oct 18, 2007, 3:05:02 PM (17 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FdoEnhancedSchemaNameSupport

    v7 v8  
    3030        • 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.
    3131
    32 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:
     32A 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:
    3333
    3434        http://www.mycity.on.ca/departments/transportation/Roads
    … …  
    194194        • 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.
    195195
    196         • 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.
     196        • 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.
    197197
    198198Conclusions:
    … …  
    278278Cons:
    279279
    280         • More complicated API. Client must create set of override classes, instead of just setting the schema name attributes or FdoXmlFlags.
     280        • More complicated API. Client must create set of override classes, instead of just setting the schema name attributes or !FdoXmlFlags.
    281281
    282282        • 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.
    … …  
    322322
    323323
    324 Currently, FdoFeatureSchemaCollection is the highest level schema object. Under this option FdoSchemaNamespaceCollection would become the highest level object.
     324Currently, !FdoFeatureSchemaCollection is the highest level schema object. Under this option !FdoSchemaNamespaceCollection would become the highest level object.
    325325
    326326The 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.
    … …  
    363363Pros:
    364364
    365         • 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.
     365        • 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.
    366366
    367367        • Better than the Schema Override approach since a separate Schema Overrides set is not required to customize schema name translation between FDO and GML.
    … …  
    377377        • Schema names themselves no longer unique, unless also qualified by namespace. Some applications might rely on schema names being unique
    378378
    379         • 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.
     379        • 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.
    380380
    381381        • 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.
    … …  
    384384
    385385        • This option is viable but not recommended. The main reasons are:
    386                 o it departs from the OpenGeospatial schema model
     386                o it departs from the !OpenGeospatial schema model
    387387                o it adds complication to the FDO Feature Schema model
    388388                o the implementation effort is a bit high.
    … …  
    391391==== Just a Name ====
    392392
    393 Under this option, namespace would not be a fully fledged Fdo Schema Element but merely a new attribute on FdoFeatureSchema:
    394 
     393Under this option, namespace would not be a fully fledged Fdo Schema Element but merely a new attribute on !FdoFeatureSchema:
    395394
    396395{{{
    … …  
    402401}}}
    403402
    404 
    405403The 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).
    406404
    407 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:
     405!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:
    408406
    409407
    … …  
    419417
    420418
    421 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.
     419Note 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.
    422420
    423421We'd still need to add namespace to qualified schema element names and modify the feature commands to handle the namespace component.
    … …  
    427425Pros:
    428426
    429         • introduces a bit less complexity to the FDO Schema model in that there is no new FdoSchemaNamespace class.
     427        • introduces a bit less complexity to the FDO Schema model in that there is no new !FdoSchemaNamespace class.
    430428
    431429Cons:
    432430
    433431        • less flexible since FdoIDescribeNamespace cannot retrieve schemas for all namespaces.
    434         • an extra command is required to list namespaces, since there is no FdoSchemaNamespaceCollection class.
     432        • an extra command is required to list namespaces, since there is no !FdoSchemaNamespaceCollection class.
    435433
    436434Conclusion:
    437435
    438         • 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.
     436        • 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.
    439437
    440438