Changes between Initial Version and Version 1 of FDORfc46


Ignore:
Timestamp:
Dec 23, 2009, 5:22:02 AM (14 years ago)
Author:
jng
Comment:

rfc46 draft

Legend:

Unmodified
Added
Removed
Modified
  • FDORfc46

    v1 v1  
     1= FDO RFC 46 - Schema Attributes Capability =
     2
     3This page contains a request for comments document (RFC) for the FDO Open Source project. 
     4More FDO RFCs can be found on the [wiki:FDORfcs RFCs] page.
     5
     6== Status ==
     7 
     8||RFC Template Version||(1.0)||
     9||Submission Date||(Dec. 23 2009)||
     10||Last Modified||(Jackie Ng) [[Timestamp]]||
     11||Author||(Jackie Ng)||
     12||RFC Status||(draft)||
     13||Implementation Status||(draft)||
     14||Proposed Milestone||(3.5.0.0)||
     15||Assigned PSC guide(s)||(when determined)||
     16||'''Voting History'''||(vote date)||
     17||+1||||
     18||+0||||
     19||-0||||
     20||-1||||
     21 
     22== Overview ==
     23
     24The RFC extends the FDO capability API so that providers can indicate support for persistence of custom schema attributes.
     25
     26== Motivation ==
     27
     28Quoting the API description of [http://fdo.osgeo.org/files/fdo/docs/FDO_API/d1/d91/class_fdo_schema_attribute_dictionary.htm FdoSchemaAttributeDictionary]:
     29
     30The FdoSchemaAttributeDictionary class maintains a dictionary of named attributes that provide a generic extensibility mechanism for objects in the feature schema. This mechanism can be used to dynamically extend schema elements in either an application or provider-specific manner.
     31
     32It has come to my attention that not all providers support the persistence of custom schema attributes. At the moment there is no way for a client application to determine if a given provider has the ability to persist any custom attributes/metadata that would be attached to a Feature Schema (that is used for a FdoIApplySchema command)
     33
     34== Proposed Solution ==
     35
     36Add a new API to FdoISchemaCapabilities:
     37
     38{{{
     39        /// \brief
     40        /// Determines if the provider supports persistence of custom attributes in schema
     41        /// elements (Feature Schema, Class Definition, Property Definition)
     42        ///
     43        /// \return
     44        /// Returns true if the provider supports custom schema attributes
     45        ///
     46        FDO_API virtual bool SupportsCustomSchemaAttributes() = 0;
     47}}}
     48
     49Providers will need to implement this new API and indicate their support.
     50
     51Providers that can persist custom schema attributes would return true. Providers that can't would return false.
     52
     53To my current knowledge, the current level of support is as follows:
     54
     55||Provider||Supports custom attributes||
     56||SDF||false||
     57||SHP||false||
     58||ArcSDE||false||
     59||WFS||false||
     60||WMS||false||
     61||ODBC||false||
     62||MySQL||true||
     63||GDAL||false||
     64||OGR||false||
     65||PostGIS||false||
     66||King.Oracle||false||
     67||SQL Server||true||
     68||SQLite||false||
     69
     70This table is based on the assumption that providers based on the Generic RDBMS framework that utilise f_* metaschema tables (MySQL, SQL Server) would support custom attributes since they are stored in the f_sad table. OGR and ODBC are assumed to not support them due to the "catch-all" nature of these providers. Support in other providers is currently unknown and assumed to be false.
     71
     72A formal capability API would greatly clear such assumptions.
     73
     74== Implications ==
     75
     76This is an API addition. This only affects client applications that wish to extend FDO feature schemas with custom metadata. It is unknown how much MapGuide will be affected. More discussions will reveal the extent that these changes will affect.
     77
     78== Funding/Resources ==
     79
     80TBD