Yes - this is the reason we renamed it "app-schemas" - the idea is the
schema is defined by a wider application that is implemented using a
services architecture.

Of course one could publish an "introspective schema" (i.e. based on
your private persistence model) as an application schema, but no-one
else could repeat it without either an identical persistance
technology and model, or the app-schema function to map things, so
we're back where we were.

so, there is a necessity to have the app-schema capability to support
open standards for data transfer, regardless of how complex they are,
and this is why the connection is obvious.

This may raise eyebrows, but its just a natural progression of the
service architecture paradigm, and pretty much unavoidable if we use
OGC or other document/literal service styles.

Rob

On Tue, Sep 22, 2009 at 8:29 AM, Andrea Aime <[email protected]> wrote:
> Ben Caradoc-Davies ha scritto:
>> I have added an introductory page on complex features.
>> http://docs.geoserver.org/trunk/en/user/data/app-schema/complex-features.html
>>
>> All feedback is appreciated. I think I have been fair to simple
>> features.  ;-)
>
> Yes you were, it's a good read which I would recommend most
> people to look at :-)
>
> One thing that might raise eyebrowses is that the comparison
> table in the "complex features" section appears to be
> identifying complex features with open standards.
>
> While the two are often found in combination, a standard could
> mandate a simple feature schema (in which case one would
> probably end up using the schema mapping abilities of app-schema,
> but not the generation of complex features),
> and a custom application could define a non standardized target
> schema just because the nature of the data it provides
> is better served by a complex feature setup.
>
> Cheers
> Andrea
>
>
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to