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 > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
