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
