Changes between Version 3 and Version 4 of FdoEnhancedSchemaNameSupport

Timestamp:

Oct 18, 2007, 2:45:54 PM (17 years ago)

Author:

gregboone

Comment:

--

FdoEnhancedSchemaNameSupport

@@ -111 +111 @@
 As 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/.
 
-
-
+==== Customized Schema Prefix ====
+
+The !FdoXmlFlags class provides a url attribute that allows the default osgeo schema prefix to be overridden. This url is then used to prepend schema names on writing to GML and for stripping off prefixes when reading from GML.  For example, if the url is set to www.mycity.on.ca/departments/transportation, then the FDO schema named "Roads" becomes:
+
+        www.mycity.on.ca/departments/transportation/Roads
+
+when the schema is written to GML. If this schema is read back from GML. the url prefix is removed and the FDO schema name becomes "Roads". 
+
+This method works better, for the Publish as WFS use case, than the default method. The customer can control what the GML schema name looks like and can make it reflect the URI's used by their organization. However, there is a limitation in that the same schema prefix gets applied to each schema in the schema collection. For example, if the schema contains a "Roads" and "!WaterService" schema, and the desired GML Schema names are:
+
+        www.mycity.on.ca/departments/transportation/Roads
+        www.mycity.on.ca/departments/watersewer/WaterService
+
+then each schema must be written by a separate !WriteXml() invocation, with a different url flag.
+
+For the same reason, this method works better than the default method for the Schema Exchange use case. However, there is one caveat: round trip fidelity is only preserved if the same url is specified on both !ReadXml() and !WriteXml(). Also, the GML schema name must start with the url prefix for round trip fidelity to be preserved. This might be difficult for an application to manage, especially if a different prefix is required for each schema.
+
+This method would not likely be used in the Export/Import use case, due to these extra complications in managing the prefixes for each schema. 
+
+This method is not applicable to the WFS Provider use case. 
+
+==== Short Prefix as Schema Name ====
+
+Most GML schema documents associate a short prefix with each schema name. This short prefix is used to define references to the schema, in other parts of the document. This makes the GML document smaller and more readable. The short prefix is not guaranteed to be unique within a GML document. However, it is unique for the XML element where it is defined plus all sub-elements.
+
+The !FdoXmlFlags provides a !SchemaNameAsPrefix setting. When set to true (the default is false), the short prefix becomes the FDO Schema name, when reading from GML to FDO.  This setting is only applicable to the !ReadXml() function. !WriteXml() always uses the url setting to generate the GML schema names.
+
+This method is used by the WFS Provider and works well for this use case. Although not globally unique, these prefixes are unique for a particular WFS. The prefixes are also very similar in format to a typical FDO Schema name in that they tend to be short and easily readable by humans.
+
+This method is not applicable to the other use cases, since all of these require the use of the !WriteXml() function. GML to FDO to GML round trip fidelity is not preserved. The full URI for the schema name is lost when translating to FDO, so it cannot be reliably re-constituted when translating back to GML.
+
+=== Requirements and Gap Analysis ===
+
+The current API handles the Export/Import and WFS Provider uses cases fairly well. However, the handling of the Schema Exchange and Publish as WFS use cases is cumbersome for the following reasons:
+
+• customer must usually supply a schema  prefix and must ensure that consistent prefixes are used when reading and writing the feature schemas.
+
+• due to a bug, round trip fidelity of schema names is not preserved when the schema name does not start with the schema prefix. 
+
+• For a single !ReadXml() or !WriteXml() operation, there is no way to apply a different schema prefix to each schema.
+
+• On !ReadXml(), if the GML schema name is not prefixed by the schema prefix, a messy looking FDO schema name is generated.
+
+The main requirement is to streamline the handling of these two use cases. !MapGuide currently (or plans to ) supports publishing FDO data sources through a WFS, so supporting this Publish as WFS likely takes priority over Schema Exchange. (TBD: verify !MapGuide's WFS publishing requirements).
+
+=== Recommendation Summary ===
+
+Section 'Solution Options' below explores a number of solution options. From these options, a number of recommendations can be made:
+
+• It is recommended that the  Schema Name Attributes option be implemented (see 5.2 Schema Name Attributes). Although not perfect, it is the best option mentioned in this document.
+
+• it is not currently recommended that we allow '.' and ':' in schema names (see 5.1 Simple Default Translation). However, this option would make schema names more readable so it should be explored further to see if the potential drawbacks can be addressed. 
+
+=== Solution Options === 
+
+The following lists some options for improving schema name conversion. These options are not necessarily mutually exclusive. However, it is unlikely that we'd implement them all since that would add a lot of complexity to the FDO API
+
+==== Simple Default Translation ====
+
+Under this option, the url setting for !FdoXmlFlags would no longer have a default. When no !FdoXmlFlags are specified, !ReadXml() and !WriteXml() would not usually modify the schema name, meaning that the GML and FDO names would usually be identical.
+
+''!WriteXml()'' would only modify the name if it is not a valid URI. In this case, the name would be adjusted by escaping any non-conforming characters.
+
+''!ReadXml()'' would only modify the name if it contains any escaped characters, which it would unescape. !ReadXml() would no longer escape '.' and ':'. This has implications on the !FdoFeatureSchema object in that these two characters would have to be allowed in schema names. This can be done by removing the no '.' or ':' restriction from schema element names. However, we'd need a way to indicate when these are literal characters when they appear as qualified names. One possibility is to mandate that each component of a qualified schema element name must be enclosed in double quotes when it contains a '.' or ':'. 
+
+When the url !FdoXmlFlag is specified, the behaviour would be as now: !WriteXml() would tack this url prefix onto the schema name and !ReadXml() would remove it if present.
+
+'''Pros'''
+
+• Simpler approach. For the default case, we don't need to worry about tacking on and stripping off prefixes. 
+
+• FDO Schema Names derived from GML are more readable. The names can still be long but at least they won't contain the '-dot-' and '-colon-' sequences. 
+
+• Works well for the Export/Import and Schema Exchange use cases as long as both !ReadXml() and !WriteXml() are done in FDO 3.3.0. Not applicable to the WFS Provider use case.
+
+'''Cons'''
+
+• Backward Compatibility. For the Export/Import and Schema Exchange use cases, schema name round trip fidelity is not preserved if !WriteXml() is done from pre-Slate and !ReadXml() from FDO 3.3.0 or vice versa. The reason is that one operation will use a different name translation method from the other. This is more of a problem for Export/Import. The bug mentioned above already introduces round trip fidelity problems for the Schema Exchange use case. The backward compatibility issues could be mitigated if we could detect when one of the operations was done using pre-slate. In this case the operation done in slate would use the pre-slate name translation rules. However, this eliminates the simplicity pro since we still have to keep the old name translation algorithms around.
+
+• Provider compatibility. Some providers might need changes, since current code based on assumption that schema element names do not contain '.' or ':'.
+
+• 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.
+
+Conclusions:
+
+• If we were starting from scratch, this would be a good option. However, at this stage, it is not really viable, due to backward compatibility issues, since these issues wipe out the advantages in simplicity.
+
+==== Schema Name Attributes ====
+
+Under this option, attributes would be added to the GML and FDO schemas to specify the name of the schema in the other domain.
+
+An xs:schema/fdo:name attribute would be added to the  FDO XML format, to specify the equivalent FDO name for schema.
+
+!WriteXml() would write this attribute to the GML document. 
+
+when present, !ReadXml() would take this attribute as the FDO schema name. Otherwise, the FDO Schema name would be generated from the GML name as is currently done.
+
+A globalName attribute would be added to the !FdoFeatureSchema class:
+
+!ReadXml() would set this attribute. 
+
+when present, !WriteXml() would use this attribute as the GML schema name. Otherwise, the GML schema name would be generated from the FDO schema name, as is currently done. Hopefully, the !GlobalName would be set to a valid URI. If not then !WriteXml() would escape any non-conforming characters. Alternatively, we could restrict the !GlobalName to be a valid URI. 
+
+From a semantic standpoint, the name attribute for !FdoFeatureSchema would be unique within a particular domain (e.g.: an FDO Datastore, an !FdoFeatureSchemaCollection in an application). The !GlobalName attribute would be intended to be universally unique, or least unique among all organizations that use the feature schema. 
+
+Pros:
+
+• Good for Schema Exchange  use case. Customer no longer needs to ensure the same url !FdoXmlFlag is used for both !WriteXml() and !ReadXml(). For the Schema Exchange, case it also opens up the possibility of using the Short Prefix as Schema Name method, since it eliminates the problem of reconstituting the GML schema name on !WriteXml(). 
+
+• Flexible. The GML and FDO schema name correspondences can be set on a per-schema basis.
+
+• Still a relatively simple option. Much simpler than the Schema Overrides and Schema Namespaces options discussed below. 
+
+• Good for Publish as WFS use cases. Publisher can set the GML name for each FDO schema explicitly. 
+
+• GML schema name can be persisted in an FDO Datastore.
+
+• Alternatively, GML schema name can be set on the Feature Schema just before it is converted to GML. This can easily be done via the FDO API.
+
+Cons:
+
+• There is no guarantee that these new settings will be persisted. This limits the cases where these settings can be effective. If an FDO schema goes through the following steps:
+
+• Write to GML[[br]]
+• Read GML into 3rd party application[[br]]
+• Write from 3rd party application to GML[[br]]
+• Read from GML[[br]]
+
+the fdo:schema name will likely be lost when the schema goes through the 3rd party application.
+
+FDO providers would not necessarily be immediately modified to support the GML namespace !FdoFeatureSchema attribute. Therefore, the following steps:
+
+• Read from GML[[br]]
+• Apply schema to FDO datastore[[br]]
+• Describe schema back from datastore[[br]]
+• Write schema to GML[[br]]
+
+will lose the GML Schema name if the datastore's provider does not handle it. However, this particular problem can be mitigated by ensuring that the SDF and RDBMS providers support this attribute. 
+
+This con would be applicable to the Schema Exchange and Publish as WFS use cases. Export/Import and WFS Provider would be unaffected.
+
+• For cases where the FDO schema name cannot be persisted in the GML document, it would be possible for the application to add it to the document just before it is read into FDO. This is possible to do but not quite straightforward since there is no simple FDO API to do this. It would have to be done via the Xerces DOM classes or by an XSL transformation.
+
+• There is overlap between the globalName attribute and the targetNamespace attribute on !FdoSchemaMapping (See next section), since both would represent the GML schema name. We could have a precedence rule (e.g. !FdoSchemaMapping.targetNamespace trumps !FdoFeatureSchema.globalName). However, having multiple places where the same attribute can be set makes the FDO API more complicated.
+
+Conclusions
+
+• This is a viable option. Although it doesn't help with Schema name translation in all cases, it would still handle a lot of cases
+
+• Despite the overlap with GML schema overrides, this would currently be the recommended option, since it is the best one mentioned in this document.