[Geoserver-devel] OGC changing all existing schemas in a backwards incompatible way

http://www.spatineo.com/2012/04/ogc-to-switch-to-wc3-xlink-in-july-2012/

Once upon a time people said “the beauty of standards is that there are
many to choose from”.
It seems we were not content with that and now standards released
years ago are changing under our feet? I’m speachless…

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


I have created a GeoTools Jira issue for this change:
https://jira.codehaus.org/browse/GEOT-4115

Should we defer the release of GeoServer 2.2 until this change is made, branch 2.2.x as stable, and abandon 2.1.x?

The impact of this change on app-schema and all deployments is rather large.

On 20/04/12 11:44, Andrea Aime wrote:

http://www.spatineo.com/2012/04/ogc-to-switch-to-wc3-xlink-in-july-2012/

Once upon a time people said "the beauty of standards is that there are
many to choose from".
It seems we were not content with that and now standards released
years ago are changing under our feet? I'm speachless...

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

I too find it pretty crazy that they will be changing all existing schemas. But to be honest it doesn’t surprise me.

As for getting this into 2.2… not sure. I kind of want to forget the ogc and this change and continue on. That said in terms of level of effort i think it mostly just involves updating the xlink schema and everything that depends on it. Ideally we can do this in a way that doesn’t fail when users (and oh there will be a lot of them) reference the old xlink schema.

On Fri, Apr 20, 2012 at 1:03 AM, Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com wrote:

I have created a GeoTools Jira issue for this change:
https://jira.codehaus.org/browse/GEOT-4115

Should we defer the release of GeoServer 2.2 until this change is made,
branch 2.2.x as stable, and abandon 2.1.x?

The impact of this change on app-schema and all deployments is rather large.

On 20/04/12 11:44, Andrea Aime wrote:

http://www.spatineo.com/2012/04/ogc-to-switch-to-wc3-xlink-in-july-2012/

Once upon a time people said “the beauty of standards is that there are
many to choose from”.
It seems we were not content with that and now standards released
years ago are changing under our feet? I’m speachless…

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre


For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know…and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2


GeoTools-Devel mailing list
GeoTools-Devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


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

On Fri, Apr 20, 2012 at 2:44 PM, Justin Deoliveira <jdeolive@anonymised.com.1501…> wrote:

I too find it pretty crazy that they will be changing all existing schemas. But to be honest it doesn’t surprise me.

As for getting this into 2.2… not sure. I kind of want to forget the ogc and this change and continue on. That said in terms of level of effort i think it mostly just involves updating the xlink schema and everything that depends on it. Ideally we can do this in a way that doesn’t fail when users (and oh there will be a lot of them) reference the old xlink schema.

Yeah… with OGC I already moved thought the whole cycle of disbelief, anger and quiet acceptance of the situation regardless of how nonsensical it seems.
That said, as long as we implement OGC protocols better to it right and try to play ball so that we can work with both the old and new schemas
seamlessly.

At the same time really believe it’s time to look into implementing restful alternatives to the OGC protocols so that we keep up to date
with what the client developers expects (if what I’ve seen at FOSS4G-NA is any indication, the expectation is “anything but not OGC”).

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


On Fri, Apr 20, 2012 at 12:14 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Apr 20, 2012 at 2:44 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I too find it pretty crazy that they will be changing all existing schemas. But to be honest it doesn’t surprise me.

As for getting this into 2.2… not sure. I kind of want to forget the ogc and this change and continue on. That said in terms of level of effort i think it mostly just involves updating the xlink schema and everything that depends on it. Ideally we can do this in a way that doesn’t fail when users (and oh there will be a lot of them) reference the old xlink schema.

Yeah… with OGC I already moved thought the whole cycle of disbelief, anger and quiet acceptance of the situation regardless of how nonsensical it seems.

This change must have a good reason behind it (I suppose), but it is going to create a lot of confusion on users. Crazy indeed.

That said, as long as we implement OGC protocols better to it right and try to play ball so that we can work with both the old and new schemas
seamlessly.

At the same time really believe it’s time to look into implementing restful alternatives to the OGC protocols so that we keep up to date
with what the client developers expects (if what I’ve seen at FOSS4G-NA is any indication, the expectation is “anything but not OGC”).

The developer crowd at FOSS4GNA is not necessarily representative of the user base for GeoServer / GeoTools. Many projects coming from Government still mandate OGC services.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know…and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2


GeoTools-Devel mailing list
GeoTools-Devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


Juan Marín Otero
GIS Consultant

-------Visita mi blog en---------------------
http://guachintoneando.blogspot.com

On Fri, Apr 20, 2012 at 6:23 PM, Juan Marín Otero <juan.marin.otero@anonymised.com> wrote:

That said, as long as we implement OGC protocols better to it right and try to play ball so that we can work with both the old and new schemas
seamlessly.

At the same time really believe it’s time to look into implementing restful alternatives to the OGC protocols so that we keep up to date
with what the client developers expects (if what I’ve seen at FOSS4G-NA is any indication, the expectation is “anything but not OGC”).

The developer crowd at FOSS4GNA is not necessarily representative of the user base for GeoServer / GeoTools. Many projects coming from Government still mandate OGC services.

I know, but it’s kind of new to me to participate to a 3 days conference and not remembering a single mention of OGC protocols
during conversations and presentations I’ve looked at. I was used to hear people complaining mostly, not hearing it mentioned at
all was a surprise.

That said, I’m not saying we should abandon OGC, not at all, we definitely want to keep implementing new specs as they come by
and improve our support to existing standards (thinking about optional portions of the protocol we still don’t implement).
INSPIRE in Europe guarantees there will be a OGC user base for those protocols for quite some time, and so does the application
schema community.

I’m just saying that we should also start looking more actively into RESTful equivalents of the OGC protocols to have a complete
(and up to date) set of options for data access. If we don’t we risk that our user base shrinks as people migrate to other implementations
offering what is perceived as a easier to use set of protocols.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Andrea,

I actually agree with you on all counts. On the bright side I think GS/GT has a very solid foundation to make this happen, so it’s a matter of prioritizing / executing on this vision.

2012/4/20 Andrea Aime <andrea.aime@anonymised.com>

On Fri, Apr 20, 2012 at 6:23 PM, Juan Marín Otero <juan.marin.otero@anonymised.com> wrote:

That said, as long as we implement OGC protocols better to it right and try to play ball so that we can work with both the old and new schemas
seamlessly.

At the same time really believe it’s time to look into implementing restful alternatives to the OGC protocols so that we keep up to date
with what the client developers expects (if what I’ve seen at FOSS4G-NA is any indication, the expectation is “anything but not OGC”).

The developer crowd at FOSS4GNA is not necessarily representative of the user base for GeoServer / GeoTools. Many projects coming from Government still mandate OGC services.

I know, but it’s kind of new to me to participate to a 3 days conference and not remembering a single mention of OGC protocols
during conversations and presentations I’ve looked at. I was used to hear people complaining mostly, not hearing it mentioned at
all was a surprise.

That said, I’m not saying we should abandon OGC, not at all, we definitely want to keep implementing new specs as they come by
and improve our support to existing standards (thinking about optional portions of the protocol we still don’t implement).
INSPIRE in Europe guarantees there will be a OGC user base for those protocols for quite some time, and so does the application
schema community.

I’m just saying that we should also start looking more actively into RESTful equivalents of the OGC protocols to have a complete
(and up to date) set of options for data access. If we don’t we risk that our user base shrinks as people migrate to other implementations
offering what is perceived as a easier to use set of protocols.

Cheers

Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Juan Marín Otero
GIS Consultant

-------Visita mi blog en---------------------
http://guachintoneando.blogspot.com

On 20/04/12 20:44, Justin Deoliveira wrote:

Ideally we can do this in a way that doesn't fail when users (and oh there will be a lot of them) reference the old xlink schema.

Apparently OGC plan to take down the old schema.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On 21/04/12 00:47, Andrea Aime wrote:

I'm just saying that we should _also_ start looking more actively into
RESTful equivalents of the OGC protocols to have a complete
(and up to date) set of options for data access. If we don't we risk
that our user base shrinks as people migrate to other implementations
offering what is perceived as a easier to use set of protocols.

WFS change request 11-080 "A REST binding for WFS 2.0" by Peter Vretanos is currently under consideration by WFS/FES SWG:
https://portal.opengeospatial.org/files/?artifact_id=44852

From here:
http://www.opengeospatial.org/standards/cr

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On 21/04/12 00:23, Juan Marín Otero wrote:

On Fri, Apr 20, 2012 at 12:14 PM, Andrea Aime
    Yeah... with OGC I already moved thought the whole cycle of
    disbelief, anger and quiet acceptance of the situation regardless of
    how nonsensical it seems.
This change must have a good reason behind it (I suppose), but it is
going to create a lot of confusion on users. Crazy indeed.

I have it on good authority that the OGC is just as unhappy with this change as developers are. They were able to obtain an extension for over six months. This backwards-incompatible change was chosen as the least-bad option.

Remember that OGC is an industry standards body funded by corporate subscriptions. Many corporate members are vendors to the US government, as are many users of GeoServer and GeoTools-based products. In the end, this rather large customer is right. While the manner of how we get there might be unpleasant, we will be left with one internationally accepted XLink specification, and that is a good thing.

I have added the announcement text to the Jira issue:
https://jira.codehaus.org/browse/GEOT-4115

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On Mon, Apr 23, 2012 at 3:41 AM, Ben Caradoc-Davies <
Ben.Caradoc-Davies@anonymised.com> wrote:

On 20/04/12 20:44, Justin Deoliveira wrote:

Ideally we can do this in a way that doesn't fail when users (and oh
there will be a lot of them) reference the old xlink schema.

Apparently OGC plan to take down the old schema.

So what? Every well designed software around has its own copies of the OGC
schemas, only a fool would
assume the OGC schemas site is always up and always accessible (think
running in a restricted enviroment
for example, or just having a bad network connection day in an app that
regardless serves mostly
the internal network).

Plus lots of sofware is hard-coded to follow the old schemas.

This means we'll have to support both the new and the old

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On Mon, Apr 23, 2012 at 4:27 AM, Ben Caradoc-Davies <
Ben.Caradoc-Davies@anonymised.com> wrote:

On 21/04/12 00:23, Juan Marín Otero wrote:

On Fri, Apr 20, 2012 at 12:14 PM, Andrea Aime
   Yeah... with OGC I already moved thought the whole cycle of
   disbelief, anger and quiet acceptance of the situation regardless of
   how nonsensical it seems.
This change must have a good reason behind it (I suppose), but it is
going to create a lot of confusion on users. Crazy indeed.

I have it on good authority that the OGC is just as unhappy with this
change as developers are. They were able to obtain an extension for over
six months. This backwards-incompatible change was chosen as the least-bad
option.

Remember that OGC is an industry standards body funded by corporate
subscriptions. Many corporate members are vendors to the US government, as
are many users of GeoServer and GeoTools-based products. In the end, this
rather large customer is right. While the manner of how we get there might
be unpleasant, we will be left with one internationally accepted XLink
specification, and that is a good thing.

Ben, look, if a change is necessary for some reason you have to go and make
revision n+1 of the standard
and deprecate the old standards, not change standards released years ago
under the software feet.
The idea that I can release a software compliant with version X of a spec
in 2005 and have it magically
become incompatible in 2012 is inconceivable, it's a if electrical sockets
could magically change their shape
overnight and all your equipment at home suddenly becomes unusable

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On 23/04/12 14:39, Andrea Aime wrote:

On Mon, Apr 23, 2012 at 3:41 AM, Ben Caradoc-Davies<Ben.Caradoc-Davies@anonymised.com<mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:

On 20/04/12 20:44, Justin Deoliveira wrote:
Ideally we can do this in a way that doesn't fail when users (and oh there will be a lot of them) reference the old xlink schema.

Apparently OGC plan to take down the old schema.

So what? Every well designed software around has its own copies of the OGC schemas, only a fool would
assume the OGC schemas site is always up and always accessible (think running in a restricted enviroment
for example, or just having a bad network connection day in an app that regardless serves mostly
the internal network).
Plus lots of sofware is hard-coded to follow the old schemas.
This means we'll have to support both the new and the old

gt-xsd-core Configuration assumes that namespaces uniquely identify schemas. hashCode and equals are defined in terms of the namespace URI, which are the same ( http://www.w3.org/1999/xlink ) for the OGC and W3C XLink schemas. As soon as someone tries to combine schemas that use both the old and new XLink, and they will, Bad Things Will Happen.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On 23/04/12 14:43, Andrea Aime wrote:

Ben, look, if a change is necessary for some reason you have to go and make revision n+1 of the standard
and deprecate the old standards, not change standards released years ago under the software feet.
The idea that I can release a software compliant with version X of a spec in 2005 and have it magically
become incompatible in 2012 is inconceivable, it's a if electrical sockets could magically change their shape
overnight and all your equipment at home suddenly becomes unusable

I asked Simon Cox and he had this response (republished here with his permission):

*** Begin quote of Simon Cox, footnote in [square brackets] is Ben ***

Actually OGC has a careful definition of compatibility. It is defined at the XML document instance level. OGC implicitly reserves the right to change schemas as long as previously valid instances are still valid. In this case the argument is that since the xlink:XXX attributes have not changed and ditto the xlink namespace, then there is no real change.

The sockets will not change shape overnight. Its more analogous to when the bills started coming from Synergy instead of Western Power [1]. If you carried on sending your cheque to Western Power your electricity would stop being supplied.

*** End quote ***

[1] In 2006 Western Australia broke up its state-owned electricity provider Western Power; Synergy is the new electricity retailer.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On Mon, Apr 23, 2012 at 9:37 AM, Ben Caradoc-Davies <
Ben.Caradoc-Davies@anonymised.com> wrote:

Actually OGC has a careful definition of compatibility. It is defined at
the XML document instance level. OGC implicitly reserves the right to
change schemas as long as previously valid instances are still valid. In
this case the argument is that since the xlink:XXX attributes have not
changed and ditto the xlink namespace, then there is no real change.

Except for parser that look for the namespace instead of the prefix, like
ours, that will need to be modified to cope with both namespaces
in order to continue to function (because client software won't change
overnight, we'll get a mix of old and new namespace references
for years).
What's maybe worse is that whatever choice we make when it comes to
emitting xml and xml schema in the future some client
will be broken as a result, pretty much like with the axis order issues
which, in 2012, still forces clients to be able to receive
data in both orders, since some WFS 1.1 server does it one way, and some
other in another (that does not only include software
that is being installed today, but installation of supposedly compliant
software that have been running for years and are not
going to be upgraded anytime soon).
The intention might be to clean up things, the effect is generating
confusion for years to come

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On Mon, Apr 23, 2012 at 4:14 AM, Ben Caradoc-Davies <
Ben.Caradoc-Davies@anonymised.com> wrote:

On 21/04/12 00:47, Andrea Aime wrote:

I'm just saying that we should _also_ start looking more actively into
RESTful equivalents of the OGC protocols to have a complete
(and up to date) set of options for data access. If we don't we risk
that our user base shrinks as people migrate to other implementations
offering what is perceived as a easier to use set of protocols.

WFS change request 11-080 "A REST binding for WFS 2.0" by Peter Vretanos
is currently under consideration by WFS/FES SWG:
https://portal.opengeospatial.**org/files/?artifact_id=44852<https://portal.opengeospatial.org/files/?artifact\_id=44852&gt;

Had a very quick look. Seems like a step in the right direction, but as
long as it mandates OGC Filter and GML instead of
CQL and GeoJSON it has, imho, little chance to fly with the community that
likes to use REST services in the first place.
Mandating CQL and GeoJSON and making OGC Filter and GML optional extras
would give this proposed approach
a higher chance for acceptance imho.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------