Cheeky thoughts #234 With app-schema you could fix the ArcSDE persistence layer pollution - maybe a config utility to generate the schema and autoconfig the app-schema mapping file.
Anyone who deploys a solution relying on the technology choice behind a standard service interface needs their heads examined anyway. They are basically choosing to light a cigar on a tour of a fireworks factory, perhaps we could sell tickets to the show? Rob On Sat, Sep 5, 2009 at 2:17 AM, Gabriel Roldan<grol...@opengeo.org> wrote: > Becoming strict by default will mean no ArcSDE instance can run by > default due to the feature type names being non valid xml CName as they > have dot characters. > > That said, I like the idea of being strict by default and having a > global switch (don't we already have it on a per-service basis, and it > would mean just shipping with inversed default?). > > So, on the feature type name thing, I repeat myself saying I think > GeoTools FeatureType names shouldn't be forced to obey GML naming rules > (after all so much effort were put on the FeatureModel not being tied to > GML but to the General Feature Model), but GeoServer ones (at least WFS > ones) shall be. So, not to get that off topic, do you think we can > become strict by default _and_ patch geoserver to force type names being > gml valid? > > It wouldn't be the first time someone complains his database table > can't be published because of having a space in the name, etc? > > Option 1, which I don't quite like, would be wrapping so type names are > escaped somehow. > > Option 2, depend on the resource/publish split and would be assigning an > escaped layer name, but may be we could alleviate by assigning an > escaped alias in the mean time? > > Gabriel > > David Winslow wrote: >> What about a global configuration option that controls whether >> strictness is enforced by default? Maybe we could include a validation >> report in exception messages? There may be something between black and >> white here. >> >> -- >> David Winslow >> OpenGeo - http://opengeo.org/ >> >> On Fri, 2009-09-04 at 07:32 -0600, Justin Deoliveira wrote: >>> As always this is a tough call. When thinking just about the user who is >>> hacking up a one off request, I agree strictness is probably the way to >>> go. But what about people who have sizable client applications built >>> that rely on this tolerance by default? Even a simple change such as >>> adding a parameter to the request (?strict=false) can make the upgrade >>> to 2.0 a deal breaker if we are talking about many clients deployed. >>> >>> Anyways, i am not against this, i just think that we will run into a >>> "grass is greener" situation in which once we enable the flag, instead >>> of running into many confused users, we will run into many irate ones >>> whose applications stop working. >>> >>> Interested in hearing other peoples opinions. This should probably be >>> discussed on the users list. I am in particular interested to hear from >>> those who have already gone through an upgrade and dealt with xml >>> parsing behavior changes. >>> >>> 2c. >>> >>> >>> Andrea Aime wrote: >>>> Hi, >>>> the 2.0 in the release is there to signify a change. It's the UI, it's >>>> the config subsystem. >>>> >>>> I was wondering if it could be a good occasion to start being strict >>>> about xml request schema compliance? >>>> We could have a flag and make strict the default, but allow people to >>>> turn that off and fall back on the non strict behavior. >>>> >>>> I'm asking this because I keep on hearing people confused because >>>> the parser just skips over the elements it does not understand >>>> and people are left wondering what's wrong. I know that one >>>> can append ?strict=true to the url to have schema validation >>>> done, the problem is that those users tripping into the lack >>>> of error messages don't ;-) >>>> >>>> Cheers >>>> Andrea >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > -- > Gabriel Roldan > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
