Thanks Adrian. I should note that it is mainly Gabriel Roldán's work, with a bit of rust removal and a fresh coat of GeoAPI 2.2 paint.
You are correct in noting that "application" is a rather overloaded term. I would not dare to use it outside the phrase "application schema," which has a precise meaning in this domain. The introduction to ISO 19109 "Rules for application schema" contains the following: "An application schema provides the formal description of the data structure and content required by one or more applications. An application schema contains the descriptions of both geographic data and other related data." In short, AppSchemaDataAccess supports the creation of geographic XML documents that are formally described by an application schema. One reason for the change is to remove the confusing and incorrect use of "simple" and "complex" from discussions of AppSchemaDataAccess. GeoServer does not even support OGC Simple Features Profile Level Zero, because it does not permit the encoding of MeasureType (a number with uom attribute) or CodeType (a string with a codeSpace attribute). SimpleFeature as used in GeoTools/GeoServer is a bit misleading. Perhaps it should be called SimplerFeature? ;-) Application schemas need not be complex; they might conform to an OGC Simple Features Profile. We also considered "public" or "published" to describe this module (we would then have had PubSchemaDataAccess), but application schemas need not be published or public, because they might be internal to an organisation. The key distinction is between XML documents formally described by an application schema, and those produced by current GeoServer releases, which are not. Notwithstanding the above remarks, we are of course happy to change the name of the module and classes if the community feels that app-schema is too confusing. Kind regards, Ben. Adrian Custer 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 >> > -- Ben Caradoc-Davies <[EMAIL PROTECTED]> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------- 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
