Rob Atkinson ha scritto:
>> A) Be nice to users with malformed requests, and do our best to interpret their mangled XML, no matter how totally mangled it is.
>> B) Be less nice to users with malformed requests, and provide a nice exception that indicates why we couldn't handle their request.
>> Thoughts? I guess I'd probably be a jerk and say that B is better.
> +1 for B too - in general we need to improve the error reporting, and
> encouraging bad behaviour will only make it harder to keep working when
> we change things, since we'll no longer just have the specs for
> guidance, but all the known and unknown bad behaviour we rely on.
> That said, if very common platforms have specific limitations, we could
> consider a workaround, until such time as they fix the problem, and
> after that start throwing an error advising people to upgrade the client.
I agree on B, have better error reporting. Otherwise people will start
building apps that don't rely on standards, but on our workaround, and
will have trouble making them talk with other servers (see for example
QGis, that will only talk WFS with MapServer afaik).
A reflector may be nice, provided it's clear it's something totally
out of standard, for your convenience, etc. That is, make it clear you
can use it be simplify coding tasks. On that point of view, I'd see
a reflector as a good idea on GET requests, but I'm dubious on POST
ones where you have an XSD that mandates a certain structure (it's not
like GET does not have a specified form, but it's not as machine
checkable, explicit, and XML ones).