[Geoserver-devel] GeoServer 2.0: a good occasion to become strict?

GeoServer GeoServer Developer
1

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 :wink:

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

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 :wink:

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

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 :wink:
>
> Cheers
> Andrea
>

4

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 :wink:

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.

5

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<groldan@anonymised.com> 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 :wink:

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

6

Rob Atkinson ha scritto:

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, whilst of course no one can dictate what you think, you should be
tactful enough not to share these offensive thoughts with the mailing list.
A open source community should be welcoming, by not getting that
you're damaging GeoServer as a whole and dropping a bad light on your
otherwise positive contributions.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

7

Sorry to anyone who is offended by my jocular tone - the point is
probably sound however, if anyone wants more serious exposition on the
basic principles of encapsulation and Service Oriented Architectures
I'll help with some references. These are not "my" thoughts at all - I
hoped I had provided enough warning that I was going to be cheeky in
tone. I acknowlegde that its not possible for anyone to have all the
relevant skills and experience in an immature field, so I should have
stuck to a dry, factual tone that minimises opportunities for
cross-cultural misinterpretation. My bad.

Please, if anyone is offended, make it known direct to me, I was not
intending to be offensive and am quite a friendly guy in person - its
not fair to expect Andrea to be the policeman on other's behalf.

Rob

On Sat, Sep 5, 2009 at 3:19 PM, Andrea Aime<aaime@anonymised.com> wrote:

Rob Atkinson ha scritto:

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, whilst of course no one can dictate what you think, you should be
tactful enough not to share these offensive thoughts with the mailing list.
A open source community should be welcoming, by not getting that
you're damaging GeoServer as a whole and dropping a bad light on your
otherwise positive contributions.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

8

There is one other option; for tables that cannot be published as is ... leave them unpublished. They will still be useful when setting up an "application schema" which provides the facilities to "remap" names.

What do you mean by an escaped alias? Something simple such as replacing "invalid" name characters with an "_" in the geoserver FeatureSource wrapper? Thus "foo.bar" would be published as "foo_bar".

Jody

On 05/09/2009, at 2:17 AM, Gabriel Roldan 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 :wink:

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