Hi all,
As a first experiment to run GeoServer with validation always turned on
(throwing an exception when a request is invalid) leads to the following:
* 48 test failures
* All the 1.0 demo requests fail
Remember that lovely fact that the gml 2.1.2 schema is not actually
valid. We could fix this by using the version they just recently
released. I am not sure but I think at some point Saul was going to do
this. Not sure if he actually got around to it.
I know it really sucks that error reporting is bad at the moment... but
I think turning on validation by default is the wrong path to take.
On the one hand we have users who are hacking out wfs requests with php,
or javascript, or whatever, and they are getting strange behavior
without any decent error reporting. On the other hand we open ourselves
up to completely breaking with various clients.
Its the lesser of two evils... given a choice i would choose the former.
I would rather deal with users showing up saying "Hey, my request does
not work and i don't get an error", as opposed to "Hey, GeoServer does
not work with OpenLayers/uDig/etc...".
I still like the service endpoint "wfs?lax=false", or "wfs?strict=true"
idea. It at least gives those users who this affects a possible
solution. I know there will still be lots of bug reports where we need
to ask them to try with the parameter set ... but I dont think that is
too high a price to pay. That is just my opinion though.
Anyways... thoughts?
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin,
Take a look at how the SLD validator works - it doesnt fully validate
the scheme and it sets up the default namespace for you so you dont
get a bunch of namespace errors. Its only a handful of lines long.
I think the main error's you'll get is either (a) things in the wrong
order (the parser doesnt care what the order is) and (b) missing tags
(that geotools doesnt care about). You could provide a "lax" (i.e.
checks what geotools actually cares about) .xsd to validate against.
Or you could add more error detection and reporting to the parser...
dave
On Nov 15, 2007 5:04 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
As a first experiment to run GeoServer with validation always turned on
(throwing an exception when a request is invalid) leads to the following:
* 48 test failures
* All the 1.0 demo requests fail
Remember that lovely fact that the gml 2.1.2 schema is not actually
valid. We could fix this by using the version they just recently
released. I am not sure but I think at some point Saul was going to do
this. Not sure if he actually got around to it.
I know it really sucks that error reporting is bad at the moment... but
I think turning on validation by default is the wrong path to take.
On the one hand we have users who are hacking out wfs requests with php,
or javascript, or whatever, and they are getting strange behavior
without any decent error reporting. On the other hand we open ourselves
up to completely breaking with various clients.
Its the lesser of two evils... given a choice i would choose the former.
I would rather deal with users showing up saying "Hey, my request does
not work and i don't get an error", as opposed to "Hey, GeoServer does
not work with OpenLayers/uDig/etc...".
I still like the service endpoint "wfs?lax=false", or "wfs?strict=true"
idea. It at least gives those users who this affects a possible
solution. I know there will still be lots of bug reports where we need
to ask them to try with the parameter set ... but I dont think that is
too high a price to pay. That is just my opinion though.
Anyways... thoughts?
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Justin Deoliveira ha scritto:
Hi all,
As a first experiment to run GeoServer with validation always turned on
(throwing an exception when a request is invalid) leads to the following:
* 48 test failures
* All the 1.0 demo requests fail
Remember that lovely fact that the gml 2.1.2 schema is not actually
valid. We could fix this by using the version they just recently
released. I am not sure but I think at some point Saul was going to do
this. Not sure if he actually got around to it.
I know it really sucks that error reporting is bad at the moment... but
I think turning on validation by default is the wrong path to take.
Sigh this is bad. I would like to understand more about the above errors
thought, that is, I'd like to see if doing some little isolated changes
the situation can be improved (20/80 rule), or if on the contrary we are screwed up this bad and there is no viable short term solution allowing
for good error reporting.
If we are injecting the correct schema locations in the header before
actually validating the requests, what accounts for all the failures
above? Would fixing the gml 2 schemas mitigate the situation?
What knobs are you touched in the code to enable validation (and I
mean only validation, not the full blown cite hacks thing)?
Cheers
Andrea
Sigh this is bad. I would like to understand more about the above errors
thought, that is, I'd like to see if doing some little isolated changes
the situation can be improved (20/80 rule), or if on the contrary we are
screwed up this bad and there is no viable short term solution allowing
for good error reporting.
I have yet to analyze what the failures actually are. And yeah... not
ideal but giving a user a way to get a good error message is better than
nothing. But I agree that more time must be spent looking at what the
failures actually are.
If we are injecting the correct schema locations in the header before
actually validating the requests, what accounts for all the failures
above? Would fixing the gml 2 schemas mitigate the situation?
What knobs are you touched in the code to enable validation (and I
mean only validation, not the full blown cite hacks thing)?
Actually I don't think the schema location is much of a problem after
looking at it. Its only really an issue in a transactions where features
whose types are defined by geoserver are being included in the request.
For a standard wfs request the schema location can be left on or off.
The parser will still validate against that schema.
Cheers
Andrea
!DSPAM:4007,473d7082151042458217002!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org