Yep - as I said I should have been more paranoid. Again, you are correct, its not an ideal solution for production, but to allow people to adopt (and hence resource) Geoserver as an option because they can test the other 95% of the functionality while a bug is fixed, or support a couple of feature types that dont require massive performance but are required to meet community expectations.
DescribeFeatureType should reference the target schema (not create a new one), so you dont actually need to fix it. The main reasons for people actually using XSLT we have seen include normalisation of data (only in-lining an object once, then referencing it) multiple multi-valued properties handling null values (and occasionally more pure polymorphism issues). (the other reasons are making things schema-valid in the first place) These all tend to substitute one schema-valid non-optimal implementation with another schema-valid solution that adds value, and meets the Data Product requirements (which are always a superset of the data structure requirements governed by XML Schemas) If hijacking the format is only triggered for configured cases, this shouldnt negatively impact the robustness of the core solution. Rob On Fri, Nov 28, 2008 at 9:50 PM, Andrea Aime <[EMAIL PROTECTED]> wrote: > Rob Atkinson ha scritto: > > Hem Rob, can you please keep the ml cc'ed? > >> Thanks for the clarifications about your intentions. We'll liaise if >> we want to exploit this feature in the short term. >> >> I may have failed to convince you, but at least a dozen significant >> (in the spatial data provision and best-practice setting) >> organisations have chosen Deegree or home-grown hacks as a short term >> solution because of this "corner case" - they actually failed to fully >> articulate requirements until the last few days and we found that 5% >> case where we couldnt do it "out-of-the-box" became a killer. > > I'm still puzzled on how this can be used for anything other than > a last minute fix for a demo. On a real production server with real > clients hitting it, how do you cope for the changes in the structure > of the feature type when a filter tries to handle it? > Moreover, this kind of change would not require hijacking only the > standard GML output, but also the DescribeFeatureType response > (by all means doable as well, but before considering poking with > code that works and risk introducing bugs I need a solid > case). > The beauty of an output format is that it does not touch at all > the core WFS code so if any bug is lurking, it affects only that > part of the code. (GeoServer _must_ be solid, I won't settle > for anything less than production ready) > >> My bad for not investing in this solution as a backup strategy, but I >> thought a year's effort cajoling test cases had us reasonably safe, >> until like a flock of starlings they all suddenly decided on a model >> change at the last moment. > > Sigh, adding an XSLT thing to your branch would have been a matter of > a few days work, you should have told us... > >> Very pleased to hear your strategy wont preclude the hijack option - >> that's really all I wanted to raise. >> >> We may even be able to resource the effort in the new year, save you a >> weekend. > > Now that would be nice :) > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > ------------------------------------------------------------------------- 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=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
