The name Application Schemas seemed most appropriate, because it directly exploits GeoAPI's implementation of the ISO feature model, which in turn is part of the ISO reference model (IS01901) which defines "Application Schemas".
An application schema is simply though of as being defined by an application - i.e. both a client and the server need to know about it. This is the basic "Design by contract" pattern. Experience has shown that the schema cannot fully describe the contract, so DescribeFeatureType is insufficient, but a "well known schema" as part of a more complete contract is necessary. As soon as the external contract is recognised then it becomes obvious that introspection of a single instance of persistent data stroes is not a good way to achieve interoperability, hence the focus on application schemas, defined by an application. BTW, the INSPIRE process is currently testing its "community" application schemas, and CSIRO Land & Water will be using Geoserver "application schemas" (ideally via trunk) to test the Hydrography theme. Anybody else interested or involved in this please contact me at [EMAIL PROTECTED] Rob Atkinson On Mon, Nov 10, 2008 at 7:12 PM, Adrian Custer <[EMAIL PROTECTED]> wrote: > Hey, > > Congratulations on the work. > > Could you explain the rationale for the "Applications" name? As I > understand it (badly), your work aims to build a mechanism for access to > data defined through 'multiple', possibly 'distant', schemas. In that > context "Application" at best means nothing at worst is misleading to > new users. But perhaps that is wrong; either way, we need a rationale > that we pass on to users when they ask questions. > > cheers, > --adrian > > > On Mon, 2008-11-10 at 11:01 +0900, Ben Caradoc-Davies wrote: >> To better conform to ISO 19101 nomenclature, after discussions with Rob >> Atkinson and others, I have renamed the GeoTools unsupported module >> community-schemas to app-schema on trunk. This change resolves the >> misleading complex/community-schemas naming tangle. >> >> Some significant changes: >> >> (1) Renamed classes ComplexDataStore* -> AppSchemaDataAccess*. >> >> (2) Renamed artifact gt-community-schemas-ds -> gt-app-schema. >> >> (3) Renamed containing module directory community-schemas -> app-schema. >> >> (4) Changed dbtype connection parameter from "complex" to "app-schema". >> >> The module app-schema now compiles and all unit tests pass. No >> regression tests have been performed as GeoServer integration has not >> been performed. >> >> Consider this software to be pre-alpha. >> >> More notes on the port can be found here: >> https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/GeoserverPortToTrunk >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
