I think I've missed how this will break backward compatibility with existing deployments, making the server respect the feature type definition and canonical schema as defaults would leave things alone, but allow new implementations to be richer. If old clients cant parse new features, it still doesnt break old deployments, and client will catch up.
but I do agree that it is a hole in the OGC architecture - its reather weak on interoperability contracts between service operations - capabilities docs are very ad-hoc. Rob On Thu, Nov 18, 2010 at 7:37 PM, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Thu, Nov 18, 2010 at 7:00 AM, Rob Atkinson <robatkinson...@gmail.com> > wrote: >> App-schema allows clients to use style sheets to deal with responses. >> (Because its a known schema, a stylesheet can be published and used to >> render it. I have build clients with catalogues of stylesheets for >> each feature type - and no way would it be worth bother with ad-hoc >> flat schemas). We build an entire enterprise content magement, >> project tracking and time-sheeting system using WFS, and also Local >> government facilities booking systems based on this, >> off-theshelf-desktop GIS is the niche market here, compared to >> business Web applications. >> >> general purpose GIS clients arent particulary useful getFeatureInfo >> endpoints anyway - enableing actual applications to be built with the >> services is a higher priority. > > I disagree. GeoServer is for today production systems, R&D is important > for the future but should never be allowed to break production readiness > in common situations (app schema and complex features are good, > but they should not break our existing simple feature user base). > Before going on with such changes I suggest, as I already did in my > previous mail, to do a reality check and see what other server do > and what clients can accept, and come out with a solution that > does not make GeoServer an oddball existing systems cannot talk to. > >> if the describeFeaturetype response delivers a gml 3 schema, >> getFeatureInfo should respect that for the same feature types - >> otherwise how will a client ever know what to trust? > > I think there is confusion here. GetFeatureInfo is for WMS, which > is a different service than WFS: one cannot simply go and assume > what is published by WFS has any influence over the WMS outputs. > The only link between the two, spec wise, is provided by the SLD > spec, which has the DescribeLayer call which in turn links > back to DescribeFeatureType (a WFS 1.0 one, btw). > However that is meant for clients > that need to build their own SLD, I don't recall ever seeing any > indication of a link between that and the GetFeatureInfo output. > > Moreover, if you look at the WMS 1.3 spec you'll see that there > is no mention anymore of the output format that GetFeatureInfo > is supposed to support. > > It would be easier, imho, to have some conventional name that > returns the gml in the app-schema form, and leave the WMS 1.1 > suggested mime type be, possibly by returning some flattened > form of the complex feature, or nothing at all. > > Cheers > Andrea > > ----------------------------------------------------- > Ing. Andrea Aime > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ----------------------------------------------------- > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
