I see - so any place we have getSchema() in our API we would need to add access to the descriptor.
That does agree with providing the same information WFS DescribeFeatureType provides (element name and type). On Sat, Mar 14, 2009 at 6:51 PM, Andrea Aime <[email protected]> wrote: > [email protected] ha scritto: > ... >> And note that this is such a need that if there's too much resistence >> to add (or better replace) FC.getSchema by FC.getContentDescriptor, >> Ben will still be able to do achieve his gloal by getting the >> descriptor from the first feature instance in the collection.... but >> we don't want to force him to that hack :) > > Ok, let's assume for a moment we go for the change described in > http://jira.codehaus.org/browse/GEOT-2385, that is, > "Extend FeatureCollection by adding getDescriptor()" > > My first reaction is... why just FeatureCollection? From what > I know: > - featureCollection.getSchema() is, in the common case, only > a reflection of featureSource.getSchema() (factoring in > the eventual changes due to Query attribute filtering) > - featureSource.getSchema() is, in the common case, only a > reflection of dataStore.getSchema(<typeName>) > > So, if we don't consider for a moment sources and collection > that do their own transformations, why is it ok to add > getDescriptor() only to FeatureCollection? > If the "General Feature Model" really requires a descriptor > for the feature type, then why don't we have also: > FeatureSource.getDescriptor(typeName) > DataAccess.getDescriptor(typeName) > > Just adding it to FeatureCollection seems a way to deal with a > contingent issue in WFS encoding, but breaks consistency. > If this is the case, you can create a WFSFeatureCollection > in the WFS module that gives you what you need in terms of > XML schema descriptors and be done with it. > (the encoders implementation should do > instanceof checks, as they are soon to be used in > WPS output where, in the normal case, no app schema is involved). > > Cheers > Andrea > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
