Will it help if we aim for CITE compliance with 2.0, using the app-schemas stuff.?
For people who will care about CITE, they are probably going to care about app-schema support as well (cf. INSPIRE). IMHO we could afford to let CITE conformance slide for pre 2.0 versions - in much the same way as we dont try to certify OGC conformance for every release. i.e. Put the energy into optimising performance and hack-free configuration for 2.0. The question is if we lose people not willing to wait till 2.0? Would be good to do a poll of people to see what combination of requirements they have. It deosnt make sense to talk about INSPIRE's requirements without supporting INSPIRE compliant app-schemas for example, so optimising 1.7 performance to meet thier needs doesnt really make much sense. NB This way we are still free to have a non-compliant (to a published standard) but fast format(s) that takes shortcuts for people who care more about performance than transparency of contract. Effectively 1.7 only supports these, no big deal perhaps? Rob On Wed, Apr 15, 2009 at 12:39 AM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > Andrea Aime wrote: >> Andrea Aime ha scritto: >>> I don't care if we run the cite tests a bit slower. >>> What I'm worried about is that we would remove some test coverage on >>> the case that people do really run in production, since the CITE tests >>> would not test it anymore. >>> Are you sure our unit tests provide the same coverage over GML encoding >>> as the cite tests do? >> >> And oh, forgot to mention the obvious, but if the new encoder can >> get in the same ballpark as the old encoder speed wise, the whole >> argument of discussion ceases to exist, we can have the new encoder >> as the only one, use it always, test and production, and don't worry >> about perf issues ;-) >> I know you're working on it, wondering if we can start kicking the >> tires of your patches sooner rather than later? > > Well they are still pretty rough, the result of raw experimentation so > nothing ready to commit in patch for format. And I of course want to do > some rigorous testing before I proceed. The rest of this week is looking > pretty busy but perhaps in the next couple of weeks... >> >> Cheers >> Andrea > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
