[Geoserver-devel] xlinks.xsd and GML 2

Hello

We’re experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType.

I.e. http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp%3Astates

The problem seems to be different includes of xlinks.xsd.

http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd.

It also includes geometry.xsd (http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd)

This file imports xlinks from “…/…/xlink/1.0.0/xlinks.xsd” (http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd)

These two separate imports makes the WFS-client go bananas.

Likely due to the fact that they are of different versions.

If we alter geometry.xsd (https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10)

to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy.

Does anyone know why two different versions are imported?

I think the OGC changed some of this stuff, and I am not sure which one geoserver uses.

Have a look at http://www.opengeospatial.org/blog/1597and let me know if it agrees with your experience. It could be either your client or geoserver needs to transition to official w3c xlink 1.1 Schema.

On Fri, Aug 21, 2015 at 6:56 AM Olle Markljung <markljung@anonymised.com> wrote:

Hello

We’re experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType.

I.e. http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp%3Astates

The problem seems to be different includes of xlinks.xsd.

http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd.

It also includes geometry.xsd (http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd)

This file imports xlinks from “…/…/xlink/1.0.0/xlinks.xsd” (http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd)

These two separate imports makes the WFS-client go bananas.

Likely due to the fact that they are of different versions.

If we alter geometry.xsd (https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10)

to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy.

Does anyone know why two different versions are imported?



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

Ok.
The clients problem is not the version but that different versions are imported at different places and both are declaring targetNamespace=“http://www.w3.org/1999/xlink”.
We can change to either schemas/xlink/1.0.0/xlinks.xsd (xlinks.xsd v3.0b2 2001-07) or schemas/gml/2.1.2/xlinks.xsd (xlinks.xsd v2.1.2 2002-07) and the client is happy.
The difference between these versions is only that the “use” attribute is added on attribute-nodes.
So, the problem is not the version but the mix of versions.

The OGC-link says that http://www.w3.org/1999/xlink.xsd should be used and that differs from the versions above.

I’d like to change the import reference in schemas/gml/2.1.2/geometry.xsd to target the xlinks.xsd in the same folder.
I can provide a PR if it would likely be accepted.

The question of complying to OGC is another issue.

···

On Fri, Aug 21, 2015 at 2:00 PM, Jody Garnett <jody.garnett@anonymised.com…> wrote:

I think the OGC changed some of this stuff, and I am not sure which one geoserver uses.

Have a look at http://www.opengeospatial.org/blog/1597and let me know if it agrees with your experience. It could be either your client or geoserver needs to transition to official w3c xlink 1.1 Schema.

On Fri, Aug 21, 2015 at 6:56 AM Olle Markljung <markljung@anonymised.com> wrote:

Hello

We’re experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType.

I.e. http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp%3Astates

The problem seems to be different includes of xlinks.xsd.

http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd.

It also includes geometry.xsd (http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd)

This file imports xlinks from “…/…/xlink/1.0.0/xlinks.xsd” (http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd)

These two separate imports makes the WFS-client go bananas.

Likely due to the fact that they are of different versions.

If we alter geometry.xsd (https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10)

to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy.

Does anyone know why two different versions are imported?



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

Let’s get some discussion going. Prepping the pull request can help, as can joining Skype meeting next Tuesday if it is not resolved by then.

···

On Fri, Aug 21, 2015 at 2:00 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I think the OGC changed some of this stuff, and I am not sure which one geoserver uses.

Have a look at http://www.opengeospatial.org/blog/1597and let me know if it agrees with your experience. It could be either your client or geoserver needs to transition to official w3c xlink 1.1 Schema.

On Fri, Aug 21, 2015 at 6:56 AM Olle Markljung <markljung@anonymised.com> wrote:

Hello

We’re experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType.

I.e. http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp%3Astates

The problem seems to be different includes of xlinks.xsd.

http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd.

It also includes geometry.xsd (http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd)

This file imports xlinks from “…/…/xlink/1.0.0/xlinks.xsd” (http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd)

These two separate imports makes the WFS-client go bananas.

Likely due to the fact that they are of different versions.

If we alter geometry.xsd (https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10)

to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy.

Does anyone know why two different versions are imported?



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

Ok,
Andrea merged my PR and I guess the CITE-tests passed (http://ares.opengeo.org/jenkins/job/cite-all/ right?).
I was unable to run the CITE-tests myself on my windows machine.

I’d like to backport the change to 2.7.x if that’s OK with you guys.
If so, I’ll fix a new PR.

I started to look at the swap to xlink 1.1 and it seems that Justin already started abit (https://github.com/geoserver/geoserver/commit/ec437677677deadb3501f16dbf6e2309ff77a9f9).
The new xsd was avaliable in gs-main but not used by any other xsd what I could see.
I was able to swap everywhere but got held up by WFS-tests failing.
I guess geotools needs to swap at the same time to match but I didn’t get much further due to not beeing able to build geotools (an artefactory seems to be down).
Has there been work/thoughts on this swap before?

I’m also curious why there are three ways to import xlink throughout the code base.
I guess referring to it locally will make it possible to build and use without internet but perhaps the same xlink.xsd could be referenced?
If so, shouldn’t all references be local?

···

On Fri, Aug 21, 2015 at 7:08 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Let’s get some discussion going. Prepping the pull request can help, as can joining Skype meeting next Tuesday if it is not resolved by then.

On Fri, Aug 21, 2015 at 7:35 AM Olle Markljung <markljung@anonymised.com…> wrote:

Ok.
The clients problem is not the version but that different versions are imported at different places and both are declaring targetNamespace=“http://www.w3.org/1999/xlink”.
We can change to either schemas/xlink/1.0.0/xlinks.xsd (xlinks.xsd v3.0b2 2001-07) or schemas/gml/2.1.2/xlinks.xsd (xlinks.xsd v2.1.2 2002-07) and the client is happy.
The difference between these versions is only that the “use” attribute is added on attribute-nodes.
So, the problem is not the version but the mix of versions.

The OGC-link says that http://www.w3.org/1999/xlink.xsd should be used and that differs from the versions above.

I’d like to change the import reference in schemas/gml/2.1.2/geometry.xsd to target the xlinks.xsd in the same folder.
I can provide a PR if it would likely be accepted.

The question of complying to OGC is another issue.


Jody Garnett

On Fri, Aug 21, 2015 at 2:00 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I think the OGC changed some of this stuff, and I am not sure which one geoserver uses.

Have a look at http://www.opengeospatial.org/blog/1597and let me know if it agrees with your experience. It could be either your client or geoserver needs to transition to official w3c xlink 1.1 Schema.

On Fri, Aug 21, 2015 at 6:56 AM Olle Markljung <markljung@anonymised.com> wrote:

Hello

We’re experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType.

I.e. http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp%3Astates

The problem seems to be different includes of xlinks.xsd.

http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd.

It also includes geometry.xsd (http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd)

This file imports xlinks from “…/…/xlink/1.0.0/xlinks.xsd” (http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd)

These two separate imports makes the WFS-client go bananas.

Likely due to the fact that they are of different versions.

If we alter geometry.xsd (https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10)

to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy.

Does anyone know why two different versions are imported?



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

I think we tried to move most of this stuff to geotools to avoid XXE problem, referencing Schema via JAR url rather than allowing file url.

···

On Fri, Aug 21, 2015 at 7:08 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Let’s get some discussion going. Prepping the pull request can help, as can joining Skype meeting next Tuesday if it is not resolved by then.

On Fri, Aug 21, 2015 at 7:35 AM Olle Markljung <markljung@anonymised.com> wrote:

Ok.
The clients problem is not the version but that different versions are imported at different places and both are declaring targetNamespace=“http://www.w3.org/1999/xlink”.
We can change to either schemas/xlink/1.0.0/xlinks.xsd (xlinks.xsd v3.0b2 2001-07) or schemas/gml/2.1.2/xlinks.xsd (xlinks.xsd v2.1.2 2002-07) and the client is happy.
The difference between these versions is only that the “use” attribute is added on attribute-nodes.
So, the problem is not the version but the mix of versions.

The OGC-link says that http://www.w3.org/1999/xlink.xsd should be used and that differs from the versions above.

I’d like to change the import reference in schemas/gml/2.1.2/geometry.xsd to target the xlinks.xsd in the same folder.
I can provide a PR if it would likely be accepted.

The question of complying to OGC is another issue.


Jody Garnett

On Fri, Aug 21, 2015 at 2:00 PM, Jody Garnett <jody.garnett@anonymised.com403…> wrote:

I think the OGC changed some of this stuff, and I am not sure which one geoserver uses.

Have a look at http://www.opengeospatial.org/blog/1597and let me know if it agrees with your experience. It could be either your client or geoserver needs to transition to official w3c xlink 1.1 Schema.

On Fri, Aug 21, 2015 at 6:56 AM Olle Markljung <markljung@anonymised.com> wrote:

Hello

We’re experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType.

I.e. http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp%3Astates

The problem seems to be different includes of xlinks.xsd.

http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd.

It also includes geometry.xsd (http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd)

This file imports xlinks from “…/…/xlink/1.0.0/xlinks.xsd” (http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd)

These two separate imports makes the WFS-client go bananas.

Likely due to the fact that they are of different versions.

If we alter geometry.xsd (https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10)

to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy.

Does anyone know why two different versions are imported?



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett