[Geoserver-devel] CITE testing results for GS 2.0-RC2

Andrea_Aime3 · October 9, 2009, 6:47pm

Here is a summary of the CITE tests results for the current
trunk (soon to become 2.0-RC2).

WFS 1.0
----------------------------------

I have problems running this one with
the new engine, keep on getting stylesheet
errors which do appear like issues with
the test script itself...

So I've run the older cite version that
I still had around for just this test.
All pass!!

WFS 1.1
----------------------------------

All pass besides the usual postgis 8.3
issue with likes on date.

WFS 1.1 xlink
----------------------------------

Had to fight quite a bit with the
data directory, the connection parameters for
H2 have changed (and at first I forgot to add
the H2 extension too).
Committed changes to the catalog.xml file so
that whoever comes after me won't have to
repeat that.

Here we have failures... given they are xlink
related there is a chance the app-schema
related changes have something to do with it?

The tests failing are:
Test wfs:wfs-1.1.0-Basic-GetFeature-tc302.1
Test wfs:wfs-1.1.0-Basic-GetFeature-tc48.1
Test wfs:GetGmlObject-POST-XML-2
Test wfs:GetFeature.XLink-POST-XML-3
Test wfs:GetFeature.XLink-POST-XML-10

Did not try to debug them as I have not much
of an understanding of the xlink subsystem,
I guess Justin can debug this much faster than me

WMS 1.1
----------------------------------

All pass

WCS 1.0
----------------------------------

One small bug made a single test fail
(capabilities generated with operations
url not ending with ?)
Fixed it, all pass

WCS 1.1
----------------------------------

Interesting one. There was a bug
introduced with the url mangler work
that made all tests fail because there
was a problem in the capabilitites document.

Once fixed the results switched to all pass.

Summary
---------------------------------

Hmmm... I can package the release tomorrow
I guess, but xlink tests are failing.
Suggestions?

Cheers
Andrea

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

jive · October 9, 2009, 10:47pm

On 10/10/2009, at 5:47 AM, Andrea Aime wrote:

Here we have failures... given they are xlink
related there is a chance the app-schema
related changes have something to do with it?

The tests failing are:
Test wfs:wfs-1.1.0-Basic-GetFeature-tc302.1
Test wfs:wfs-1.1.0-Basic-GetFeature-tc48.1
Test wfs:GetGmlObject-POST-XML-2
Test wfs:GetFeature.XLink-POST-XML-3
Test wfs:GetFeature.XLink-POST-XML-10

Did not try to debug them as I have not much
of an understanding of the xlink subsystem,

Summary
---------------------------------

Hmmm... I can package the release tomorrow
I guess, but xlink tests are failing.
Suggestions?

We would not issue dot release with cite failures; so I think we are stuck on making the release candidate.

Jody

Andrea_Aime3 · October 10, 2009, 12:26pm

Jody Garnett ha scritto:

Summary
---------------------------------

Hmmm... I can package the release tomorrow
I guess, but xlink tests are failing.
Suggestions?

We would not issue dot release with cite failures; so I think we are stuck on making the release candidate.

I've run the xlink tests using the older cite engine, got two failures,
and different from the ones I got before, and actually happening
outside of the xlink portion of tests (which do pass fully).

The first failure is wfs:wfs-1.1.0-Basic-GetFeature-tc302.1,
which requests all features that satisfy
decimalProperty = intProperty - 149.98

I've checked the sql query sent is correct and the 149.98 value
is set in the propared statement correctly, but no result comes
out. Yet, if I run the same query in the H2 console (no prepared
statements) I get the expected result.

It's probably some strange issue in how H2 handles prepared statements,
we could dodge it if H2 datastore exposed a parameter to allow
the usage of the non prepared statement path (which is coded, just not
made available).

The other test failing is wfs:wfs-1.1.0-Basic-GetFeature-tc48.1.
This one is sure strange, it first asks for all the features, then
makes a second request asking only for EntiteGenerique.4 and
EntiteGenerique.7 (accents removed on purpose to make sure the mail
does not eat them) and the results contains them... just... doubled!

Cheers
Andrea

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

Justin_Deoliveira · October 10, 2009, 3:52pm

Apologies for the late reply. I have been swamped with foss4g prep. But will look into the xlink failures now. Will report back when i have made some progress.

Andrea Aime wrote:

Jody Garnett ha scritto:

Summary
---------------------------------

Hmmm... I can package the release tomorrow
I guess, but xlink tests are failing.
Suggestions?

We would not issue dot release with cite failures; so I think we are stuck on making the release candidate.

I've run the xlink tests using the older cite engine, got two failures,
and different from the ones I got before, and actually happening
outside of the xlink portion of tests (which do pass fully).

The first failure is wfs:wfs-1.1.0-Basic-GetFeature-tc302.1,
which requests all features that satisfy
decimalProperty = intProperty - 149.98

I've checked the sql query sent is correct and the 149.98 value
is set in the propared statement correctly, but no result comes
out. Yet, if I run the same query in the H2 console (no prepared
statements) I get the expected result.

It's probably some strange issue in how H2 handles prepared statements,
we could dodge it if H2 datastore exposed a parameter to allow
the usage of the non prepared statement path (which is coded, just not
made available).

The other test failing is wfs:wfs-1.1.0-Basic-GetFeature-tc48.1.
This one is sure strange, it first asks for all the features, then
makes a second request asking only for EntiteGenerique.4 and
EntiteGenerique.7 (accents removed on purpose to make sure the mail
does not eat them) and the results contains them... just... doubled!

Cheers
Andrea

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

Justin_Deoliveira · October 10, 2009, 5:16pm

Ok, looked into the test failures. And bottom line is that the hacks put in place for xlink are tripping over work done by the app-schema folks. Before app-schema was in place i was free to make wild assumptions and hack to high heaven to get things working. But now that certain types and bindings are being used those hacks fall apart.

Unfortunately I don't see an easy way forward on this. I could spend time trying to rework my hacks but quite frankly I a) don't have the time right now and b) don't see the point. The xlink "implementation" (if you can call it that) was just an experiment (and in my opinion a premature one) in an OGC test bed. Nobody else as far as i know implements xlink, and i can't think of one client who could possibly be using it.

However it has been my intention to get rid of the nasty hacks and replace them with a working app-schema configuration now that we have one. But this is not a trivial piece of work. I spent half a day trying to do so and met limited success, and it required patches to app-schema which were not accepted at the time.

So I leave it up to the PSC to decide but if it were my call I would say ditch xlink for now until we can get a working app-schema replacement for what is there on 1.7.x. And keep the OGC happy with 1.7.x as their "xlink reference implementation" until that happens.

-Justin

Andrea Aime wrote:

Jody Garnett ha scritto:

Summary
---------------------------------

Hmmm... I can package the release tomorrow
I guess, but xlink tests are failing.
Suggestions?

We would not issue dot release with cite failures; so I think we are stuck on making the release candidate.

I've run the xlink tests using the older cite engine, got two failures,
and different from the ones I got before, and actually happening
outside of the xlink portion of tests (which do pass fully).

The first failure is wfs:wfs-1.1.0-Basic-GetFeature-tc302.1,
which requests all features that satisfy
decimalProperty = intProperty - 149.98

I've checked the sql query sent is correct and the 149.98 value
is set in the propared statement correctly, but no result comes
out. Yet, if I run the same query in the H2 console (no prepared
statements) I get the expected result.

It's probably some strange issue in how H2 handles prepared statements,
we could dodge it if H2 datastore exposed a parameter to allow
the usage of the non prepared statement path (which is coded, just not
made available).

The other test failing is wfs:wfs-1.1.0-Basic-GetFeature-tc48.1.
This one is sure strange, it first asks for all the features, then
makes a second request asking only for EntiteGenerique.4 and
EntiteGenerique.7 (accents removed on purpose to make sure the mail
does not eat them) and the results contains them... just... doubled!

Cheers
Andrea

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

Andrea_Aime3 · October 10, 2009, 7:47pm

Justin Deoliveira ha scritto:

Ok, looked into the test failures. And bottom line is that the hacks put in place for xlink are tripping over work done by the app-schema folks. Before app-schema was in place i was free to make wild assumptions and hack to high heaven to get things working. But now that certain types and bindings are being used those hacks fall apart.

Unfortunately I don't see an easy way forward on this. I could spend time trying to rework my hacks but quite frankly I a) don't have the time right now and b) don't see the point. The xlink "implementation" (if you can call it that) was just an experiment (and in my opinion a premature one) in an OGC test bed. Nobody else as far as i know implements xlink, and i can't think of one client who could possibly be using it.

However it has been my intention to get rid of the nasty hacks and replace them with a working app-schema configuration now that we have one. But this is not a trivial piece of work. I spent half a day trying to do so and met limited success, and it required patches to app-schema which were not accepted at the time.

Interesting. Is the app schema team going to work over xlink support
anytime soon? Anyone?

So I leave it up to the PSC to decide but if it were my call I would say ditch xlink for now until we can get a working app-schema replacement for what is there on 1.7.x. And keep the OGC happy with 1.7.x as their "xlink reference implementation" until that happens.

I agree with the reasoning. On one side I think we should call a PSC
vote, on the other side, a PSC vote won't materialize resources by
magic: if there is no one with the ability to work on this, it won't
be done, it's as simple as that. (no?)

Soo... opinions? Maybe we should start a separate thread to discuss this.

Cheers
Andrea

PS: does that mean we get remove the code that
in JdbcDataStore handles geometric association? :-p
Sorry, could not resist!!

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

jive · October 11, 2009, 4:41am

Okay quick sanity check question; can we "turn off" support for xlink and have the cite test skip that part? I am only focused on if we can make a release candidate today or not; and if we can make use of volunteers for to help test.

I am with Justin; ditch xlink support; get 2.0 out the door since we met our goal of having a new user interface; and make plans for xlink later when people have time to think.

A PSC vote won't actually hep or hinder right now; only hands helping out. And we have lined up hands to help test

Jody

On 11/10/2009, at 6:47 AM, Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, looked into the test failures. And bottom line is that the hacks put in place for xlink are tripping over work done by the app-schema folks. Before app-schema was in place i was free to make wild assumptions and hack to high heaven to get things working. But now that certain types and bindings are being used those hacks fall apart.
Unfortunately I don't see an easy way forward on this. I could spend time trying to rework my hacks but quite frankly I a) don't have the time right now and b) don't see the point. The xlink "implementation" (if you can call it that) was just an experiment (and in my opinion a premature one) in an OGC test bed. Nobody else as far as i know implements xlink, and i can't think of one client who could possibly be using it.
However it has been my intention to get rid of the nasty hacks and replace them with a working app-schema configuration now that we have one. But this is not a trivial piece of work. I spent half a day trying to do so and met limited success, and it required patches to app-schema which were not accepted at the time.

Interesting. Is the app schema team going to work over xlink support
anytime soon? Anyone?

So I leave it up to the PSC to decide but if it were my call I would say ditch xlink for now until we can get a working app-schema replacement for what is there on 1.7.x. And keep the OGC happy with 1.7.x as their "xlink reference implementation" until that happens.

I agree with the reasoning. On one side I think we should call a PSC
vote, on the other side, a PSC vote won't materialize resources by
magic: if there is no one with the ability to work on this, it won't
be done, it's as simple as that. (no?)

Soo... opinions? Maybe we should start a separate thread to discuss this.

Cheers
Andrea

PS: does that mean we get remove the code that
in JdbcDataStore handles geometric association? :-p
Sorry, could not resist!!

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

Justin_Deoliveira · October 11, 2009, 2:58pm

You have to explicitly specify to run the xlink tests, so very easy, just don't click the check box

Jody Garnett wrote:

Okay quick sanity check question; can we "turn off" support for xlink and have the cite test skip that part? I am only focused on if we can make a release candidate today or not; and if we can make use of volunteers for to help test.

I am with Justin; ditch xlink support; get 2.0 out the door since we met our goal of having a new user interface; and make plans for xlink later when people have time to think.

A PSC vote won't actually hep or hinder right now; only hands helping out. And we have lined up hands to help test

Jody

On 11/10/2009, at 6:47 AM, Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, looked into the test failures. And bottom line is that the hacks put in place for xlink are tripping over work done by the app-schema folks. Before app-schema was in place i was free to make wild assumptions and hack to high heaven to get things working. But now that certain types and bindings are being used those hacks fall apart.
Unfortunately I don't see an easy way forward on this. I could spend time trying to rework my hacks but quite frankly I a) don't have the time right now and b) don't see the point. The xlink "implementation" (if you can call it that) was just an experiment (and in my opinion a premature one) in an OGC test bed. Nobody else as far as i know implements xlink, and i can't think of one client who could possibly be using it.
However it has been my intention to get rid of the nasty hacks and replace them with a working app-schema configuration now that we have one. But this is not a trivial piece of work. I spent half a day trying to do so and met limited success, and it required patches to app-schema which were not accepted at the time.

Interesting. Is the app schema team going to work over xlink support
anytime soon? Anyone?

So I leave it up to the PSC to decide but if it were my call I would say ditch xlink for now until we can get a working app-schema replacement for what is there on 1.7.x. And keep the OGC happy with 1.7.x as their "xlink reference implementation" until that happens.

I agree with the reasoning. On one side I think we should call a PSC
vote, on the other side, a PSC vote won't materialize resources by
magic: if there is no one with the ability to work on this, it won't
be done, it's as simple as that. (no?)

Soo... opinions? Maybe we should start a separate thread to discuss this.

Cheers
Andrea

PS: does that mean we get remove the code that
in JdbcDataStore handles geometric association? :-p
Sorry, could not resist!!

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

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

Justin_Deoliveira · October 11, 2009, 2:59pm

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, looked into the test failures. And bottom line is that the hacks put in place for xlink are tripping over work done by the app-schema folks. Before app-schema was in place i was free to make wild assumptions and hack to high heaven to get things working. But now that certain types and bindings are being used those hacks fall apart.

Unfortunately I don't see an easy way forward on this. I could spend time trying to rework my hacks but quite frankly I a) don't have the time right now and b) don't see the point. The xlink "implementation" (if you can call it that) was just an experiment (and in my opinion a premature one) in an OGC test bed. Nobody else as far as i know implements xlink, and i can't think of one client who could possibly be using it.

However it has been my intention to get rid of the nasty hacks and replace them with a working app-schema configuration now that we have one. But this is not a trivial piece of work. I spent half a day trying to do so and met limited success, and it required patches to app-schema which were not accepted at the time.

Interesting. Is the app schema team going to work over xlink support
anytime soon? Anyone?

Well it is my understanding that theoretically the app-schema
implementation can do all the stuff needed support the xlink cite tests,
but when I tried it out i ran into a few hitches.

So I leave it up to the PSC to decide but if it were my call I would say ditch xlink for now until we can get a working app-schema replacement for what is there on 1.7.x. And keep the OGC happy with 1.7.x as their "xlink reference implementation" until that happens.

I agree with the reasoning. On one side I think we should call a PSC
vote, on the other side, a PSC vote won't materialize resources by
magic: if there is no one with the ability to work on this, it won't
be done, it's as simple as that. (no?)

I know at the app-schema workshop we had back in July working on this
was discussed, but not brought up as a priority. It would be nice to have though. CITE while often annoying has its uses when it comes to finding regressions. Plus it would be nice to boast that our complex features implementation is "cite compliant"

Soo... opinions? Maybe we should start a separate thread to discuss this.

Cheers
Andrea

PS: does that mean we get remove the code that
in JdbcDataStore handles geometric association? :-p
Sorry, could not resist!!

+1 it would be like christmas early this year!!

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

Rob_Atkinson1 · October 11, 2009, 3:21pm

app-schema is stuck on GEOT-2505 for xlink and any other gml data type
attribute support. Hopefully we can get a chance to deal with this at
FOSS4G

I am not aware of any proposed changes, especially any proposals "not
accepted" by the app-schema team - is there some changes proposed on a
back-channel, and not accepted by others that we havent been told
about? As far as I know we are waiting for some stuff to be checked in
by Justin so we could look at it, but this is about 2 months ago.

as a PSC member, I'd be happy to vote to ignore xlinks while its just
a hack - passing the CITE tests for a special case is kind of
bypassing the point of the CITE tests IMHO. These are conformance
tests for a capability - if the capability is a hack, this is not a
great situation.

Rob

On Mon, Oct 12, 2009 at 1:58 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

You have to explicitly specify to run the xlink tests, so very easy,
just don't click the check box

Jody Garnett wrote:

Okay quick sanity check question; can we "turn off" support for xlink
and have the cite test skip that part? I am only focused on if we can
make a release candidate today or not; and if we can make use of
volunteers for to help test.

I am with Justin; ditch xlink support; get 2.0 out the door since we met
our goal of having a new user interface; and make plans for xlink later
when people have time to think.

A PSC vote won't actually hep or hinder right now; only hands helping
out. And we have lined up hands to help test

Jody

On 11/10/2009, at 6:47 AM, Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, looked into the test failures. And bottom line is that the hacks
put in place for xlink are tripping over work done by the app-schema
folks. Before app-schema was in place i was free to make wild
assumptions and hack to high heaven to get things working. But now
that certain types and bindings are being used those hacks fall apart.
Unfortunately I don't see an easy way forward on this. I could spend
time trying to rework my hacks but quite frankly I a) don't have the
time right now and b) don't see the point. The xlink "implementation"
(if you can call it that) was just an experiment (and in my opinion a
premature one) in an OGC test bed. Nobody else as far as i know
implements xlink, and i can't think of one client who could possibly
be using it.
However it has been my intention to get rid of the nasty hacks and
replace them with a working app-schema configuration now that we have
one. But this is not a trivial piece of work. I spent half a day
trying to do so and met limited success, and it required patches to
app-schema which were not accepted at the time.

Interesting. Is the app schema team going to work over xlink support
anytime soon? Anyone?

So I leave it up to the PSC to decide but if it were my call I would
say ditch xlink for now until we can get a working app-schema
replacement for what is there on 1.7.x. And keep the OGC happy with
1.7.x as their "xlink reference implementation" until that happens.

I agree with the reasoning. On one side I think we should call a PSC
vote, on the other side, a PSC vote won't materialize resources by
magic: if there is no one with the ability to work on this, it won't
be done, it's as simple as that. (no?)

Soo... opinions? Maybe we should start a separate thread to discuss this.

Cheers
Andrea

PS: does that mean we get remove the code that
in JdbcDataStore handles geometric association? :-p
Sorry, could not resist!!

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

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin_Deoliveira · October 11, 2009, 3:30pm

Rob Atkinson wrote:

app-schema is stuck on GEOT-2505 for xlink and any other gml data type
attribute support. Hopefully we can get a chance to deal with this at
FOSS4G

Really, because I was able to encode xlinks with app-schema just fine, just the way things are implemented at the datastore level broke, and would be better set up with feature chaining.

Or is this just another blanket statement about things being broken due to lack of features not implemented yet?

I am not aware of any proposed changes, especially any proposals "not
accepted" by the app-schema team - is there some changes proposed on a
back-channel, and not accepted by others that we havent been told
about? As far as I know we are waiting for some stuff to be checked in
by Justin so we could look at it, but this is about 2 months ago.

I brought up the issue and briefly how I had to patch it on the mailing list but the discussion ended in Ben asking for some test cases, which I totally agreed with just did not have the time to follow through on.

as a PSC member, I'd be happy to vote to ignore xlinks while its just
a hack - passing the CITE tests for a special case is kind of
bypassing the point of the CITE tests IMHO. These are conformance
tests for a capability - if the capability is a hack, this is not a
great situation.

Agreed.

Rob

On Mon, Oct 12, 2009 at 1:58 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

You have to explicitly specify to run the xlink tests, so very easy,
just don't click the check box

Jody Garnett wrote:

Okay quick sanity check question; can we "turn off" support for xlink
and have the cite test skip that part? I am only focused on if we can
make a release candidate today or not; and if we can make use of
volunteers for to help test.

I am with Justin; ditch xlink support; get 2.0 out the door since we met
our goal of having a new user interface; and make plans for xlink later
when people have time to think.

A PSC vote won't actually hep or hinder right now; only hands helping
out. And we have lined up hands to help test

Jody

On 11/10/2009, at 6:47 AM, Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, looked into the test failures. And bottom line is that the hacks
put in place for xlink are tripping over work done by the app-schema
folks. Before app-schema was in place i was free to make wild
assumptions and hack to high heaven to get things working. But now
that certain types and bindings are being used those hacks fall apart.
Unfortunately I don't see an easy way forward on this. I could spend
time trying to rework my hacks but quite frankly I a) don't have the
time right now and b) don't see the point. The xlink "implementation"
(if you can call it that) was just an experiment (and in my opinion a
premature one) in an OGC test bed. Nobody else as far as i know
implements xlink, and i can't think of one client who could possibly
be using it.
However it has been my intention to get rid of the nasty hacks and
replace them with a working app-schema configuration now that we have
one. But this is not a trivial piece of work. I spent half a day
trying to do so and met limited success, and it required patches to
app-schema which were not accepted at the time.

Interesting. Is the app schema team going to work over xlink support
anytime soon? Anyone?

So I leave it up to the PSC to decide but if it were my call I would
say ditch xlink for now until we can get a working app-schema
replacement for what is there on 1.7.x. And keep the OGC happy with
1.7.x as their "xlink reference implementation" until that happens.

I agree with the reasoning. On one side I think we should call a PSC
vote, on the other side, a PSC vote won't materialize resources by
magic: if there is no one with the ability to work on this, it won't
be done, it's as simple as that. (no?)

Soo... opinions? Maybe we should start a separate thread to discuss this.

Cheers
Andrea

PS: does that mean we get remove the code that
in JdbcDataStore handles geometric association? :-p
Sorry, could not resist!!

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

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

Chris_Holmes1 · October 12, 2009, 3:07pm

I'm +1 on dropping xlink cite compliance for 2.0. I personally think xlink wfs is a silly operation. And don't know that it's even worth spending time on later. 1.7.x can serve as the xlink reference implementation, indeed if we wanted to certify 2.0.x as xlink compliant we'd have to pay.

One thing that would be a nice target for app-schema though is the 'complex feature' tests. GeoServer has never passed them, but app-schema opens the possibility. I think they're actually pretty basic once the app-schema infrastructure is there. Has the app-schema team checked them out? It's a check box when you run the tests.

C

Justin Deoliveira wrote:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, looked into the test failures. And bottom line is that the hacks put in place for xlink are tripping over work done by the app-schema folks. Before app-schema was in place i was free to make wild assumptions and hack to high heaven to get things working. But now that certain types and bindings are being used those hacks fall apart.

Unfortunately I don't see an easy way forward on this. I could spend time trying to rework my hacks but quite frankly I a) don't have the time right now and b) don't see the point. The xlink "implementation" (if you can call it that) was just an experiment (and in my opinion a premature one) in an OGC test bed. Nobody else as far as i know implements xlink, and i can't think of one client who could possibly be using it.

However it has been my intention to get rid of the nasty hacks and replace them with a working app-schema configuration now that we have one. But this is not a trivial piece of work. I spent half a day trying to do so and met limited success, and it required patches to app-schema which were not accepted at the time.

Interesting. Is the app schema team going to work over xlink support
anytime soon? Anyone?

Well it is my understanding that theoretically the app-schema
implementation can do all the stuff needed support the xlink cite tests,
but when I tried it out i ran into a few hitches.

So I leave it up to the PSC to decide but if it were my call I would say ditch xlink for now until we can get a working app-schema replacement for what is there on 1.7.x. And keep the OGC happy with 1.7.x as their "xlink reference implementation" until that happens.

I agree with the reasoning. On one side I think we should call a PSC
vote, on the other side, a PSC vote won't materialize resources by
magic: if there is no one with the ability to work on this, it won't
be done, it's as simple as that. (no?)

I know at the app-schema workshop we had back in July working on this
was discussed, but not brought up as a priority. It would be nice to have though. CITE while often annoying has its uses when it comes to finding regressions. Plus it would be nice to boast that our complex features implementation is "cite compliant"

Soo... opinions? Maybe we should start a separate thread to discuss this.

Cheers
Andrea

PS: does that mean we get remove the code that
in JdbcDataStore handles geometric association? :-p
Sorry, could not resist!!

+1 it would be like christmas early this year!!

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Ben_Caradoc-Davies · October 13, 2009, 2:08am

On 12/10/09 23:07, Chris Holmes wrote:

One thing that would be a nice target for app-schema though is the
'complex feature' tests. GeoServer has never passed them, but
app-schema opens the possibility. I think they're actually pretty basic
once the app-schema infrastructure is there. Has the app-schema team
checked them out? It's a check box when you run the tests.

I have seen the check box, but we have not looked at the tests.

It would be good to have a comprehensive CITE complex feature test data set and tests. I have mentioned this to some contacts in the right places, who are in agreement, but as yet I have not received a response. There is a prospect on the medium term horizon that the GeoSciML community will provide a test data set. We might be able to get this adopted as the CITE complex feature test data set.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Ben_Caradoc-Davies · October 13, 2009, 5:30am

On 11/10/09 23:30, Justin Deoliveira wrote:
[app-schema for xlink]

I brought up the issue and briefly how I had to patch it on the mailing
list but the discussion ended in Ben asking for some test cases, which I
totally agreed with just did not have the time to follow through on.

Rob, I think Justin's proposal for how to improve app-schema so it is more useful for xlink is contained in this Jira issue, which I created to capture his original email:
http://jira.codehaus.org/browse/GEOT-2679

I will soon be doing some work to improve schema handling for tests; this will allow me to get some coverage on these cases, and apply Justin's patch.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Andrea_Aime3 · October 13, 2009, 9:41am

Ben Caradoc-Davies ha scritto:

On 12/10/09 23:07, Chris Holmes wrote:

One thing that would be a nice target for app-schema though is the
'complex feature' tests. GeoServer has never passed them, but
app-schema opens the possibility. I think they're actually pretty basic
once the app-schema infrastructure is there. Has the app-schema team
checked them out? It's a check box when you run the tests.

I have seen the check box, but we have not looked at the tests.

It would be good to have a comprehensive CITE complex feature test data set and tests. I have mentioned this to some contacts in the right places, who are in agreement, but as yet I have not received a response. There is a prospect on the medium term horizon that the GeoSciML community will provide a test data set. We might be able to get this adopted as the CITE complex feature test data set.

That sounds good, but also quite a bit of work.

I quite a quick peek at the complex data required for wfs 1.1 and the
origin dataset is attached at the end of this mail. Does not look
earth shattering, the only thing is that they are using Curve
and Surface, but in fact both of them are really equivalents of
multi linestrings and multi polygons... Did not look at the requests,
but maybe passing the existing cite tests is not that hard.

Cheers
Andrea

<?xml version="1.0" encoding="UTF-8"?>
<sf:SimpleFeatureCollection gml:id="f100"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:sf="http://cite.opengeospatial.org/gmlsf"
   xmlns:xlink="http://www.w3.org/1999/xlink">

   <gml:description>
   Test data for assessing compliance with the GMLSF profile at level SF-1.
   </gml:description>
   <gml:name>CITE/WFS-1.1</gml:name>
   <gml:boundedBy>
     <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">
       <gml:lowerCorner>34.94 -10.52</gml:lowerCorner>
       <gml:upperCorner>71.96 32.19</gml:upperCorner>
     </gml:Envelope>
   </gml:boundedBy>

   <sf:featureMember>
     <sf:ComplexGeoFeature gml:id="f101">
       <gml:description>
       Aliquam sed lorem. Nam non risus ut felis pellentesque consequat. Curabitur
       pede. Suspendisse potenti. Mauris lacinia. Donec risus leo, luctus at,
       aliquet vel, congue in, mi. Mauris pulvinar mollis felis. Etiam posuere,
       ante et luctus blandit, purus metus sollicitudin nisl, eget gravida lorem
       elit sed pede. Nunc tristique elementum sem. Nullam feugiat mauris quis
       tellus. Nulla cursus augue at ipsum. Mauris volutpat posuere tellus. Quisque
       accumsan tellus sit amet elit. Nam tempor libero id urna. Donec ac sapien.
       Class aptent taciti sociosqu ad litora torquent per conubia nostra, per
       inceptos hymenaeos. Ut sollicitudin dapibus magna. Phasellus erat turpis,
       adipiscing eu, lobortis ut, convallis a, nisl. Vivamus rutrum magna eget
       metus consectetuer ultrices. Sed ac nisi tincidunt risus euismod condimentum.
       </gml:description>
       <gml:name codeSpace="http://cite.opengeospatial.org/gmlsf">name\-f101</gml:name>
       <sf:geometryProperty>
         <gml:LineString srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4979">
           <gml:posList>46.074 9.799 600.2 46.652 10.466 781.4</gml:posList>
         </gml:LineString>
       </sf:geometryProperty>
       <sf:observation uom="http://www.bipm.fr/en/si/derived_units/Celsius">2\.4</sf:observation>
       <sf:typeCode codeSpace="https://www.dgiwg.org/FAD">AQ064</sf:typeCode>
       <sf:auditTrail>
         <sf:Event>
           <sf:action>Insert</sf:action>
           <sf:timestamp>2006-06-29T12:37:00+02:00</sf:timestamp>
           <sf:userid>Phineas.Fogg</sf:userid>
         </sf:Event>
         <sf:Event>
           <sf:action>Update</sf:action>
           <sf:timestamp>2006-06-30T10:37:00+02:00</sf:timestamp>
           <sf:userid>Phineas.Fogg</sf:userid>
         </sf:Event>
         <sf:Event>
           <sf:action>Update</sf:action>
           <sf:timestamp>2006-06-30T16:07:00+02:00</sf:timestamp>
           <sf:userid>Axel.Lidenbrock</sf:userid>
         </sf:Event>
         <sf:Event>
           <sf:action>Update</sf:action>
           <sf:timestamp>2006-07-12T16:16:00+02:00</sf:timestamp>
           <sf:userid>Axel.Lidenbrock</sf:userid>
         </sf:Event>
         <sf:Event>
           <sf:action>Update</sf:action>
           <sf:timestamp>2006-09-06T09:47:07Z</sf:timestamp>
           <sf:userid>Eugène.Rastignac</sf:userid>
         </sf:Event>
       </sf:auditTrail>
     </sf:ComplexGeoFeature>
   </sf:featureMember>

   <sf:featureMember>
     <sf:ComplexGeoFeature gml:id="f102">
       <gml:description>
       Integer euismod risus. Class aptent taciti sociosqu ad litora torquent per
       conubia nostra, per inceptos hymenaeos. Phasellus nec risus.
       </gml:description>
       <gml:name codeSpace="http://cite.opengeospatial.org/gmlsf">name\-f102</gml:name>
       <gml:name>Vivamus blandit</gml:name>
       <sf:geometryProperty>
         <gml:Curve srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4979">
           <gml:segments>
             <gml:LineStringSegment interpolation="linear">
               <gml:posList>45.174 2.899 45.652 2.466 45.891 2.899</gml:posList>
             </gml:LineStringSegment>
             <gml:LineStringSegment interpolation="linear">
               <gml:posList>45.891 2.899 48.174 2.899 48.652 2.466 48.891 2.899</gml:posList>
             </gml:LineStringSegment>
           </gml:segments>
         </gml:Curve>
       </sf:geometryProperty>
       <sf:observation uom="http://www.bipm.fr/en/si/si_brochure/chapter2/2-1/metre.html">14\.1</sf:observation>
       <sf:typeCode codeSpace="https://www.dgiwg.org/FAD">SA060</sf:typeCode>
       <sf:auditTrail>
         <sf:Event>
           <sf:action>Insert</sf:action>
           <sf:timestamp>2006-10-21T11:28:00+01:00</sf:timestamp>
           <sf:userid>Axel.Lidenbrock</sf:userid>
         </sf:Event>
         <sf:Event>
           <sf:action>Update</sf:action>
           <sf:timestamp>2006-10-30T21:05:00+01:00</sf:timestamp>
           <sf:userid>Phineas.Fogg</sf:userid>
         </sf:Event>
       </sf:auditTrail>
     </sf:ComplexGeoFeature>
   </sf:featureMember>

   <sf:featureMember>
     <sf:ComplexGeoFeature gml:id="f103">
       <gml:name codeSpace="http://cite.opengeospatial.org/gmlsf">name\-f103</gml:name>
       <sf:geometryProperty>
         <gml:Surface srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">
           <gml:patches>
             <gml:PolygonPatch interpolation="planar">
               <gml:exterior>
                 <gml:LinearRing>
                   <gml:posList>37.5 6.0 37.5 8.0 40.0 8.0 40.0 6.0 37.5 6.0</gml:posList>
                 </gml:LinearRing>
               </gml:exterior>
               <gml:interior>
                 <gml:LinearRing>
                   <gml:posList>38.0 6.5 39.0 6.5 39.0 7.0 38.0 6.5</gml:posList>
                 </gml:LinearRing>
               </gml:interior>
             </gml:PolygonPatch>
             <gml:PolygonPatch interpolation="planar">
               <gml:exterior>
                 <gml:LinearRing>
                   <gml:posList>40.0 6.0 40.0 8.0 42.5 9.0 42.5 5.0 40.0 6.0</gml:posList>
                 </gml:LinearRing>
               </gml:exterior>
             </gml:PolygonPatch>
           </gml:patches>
         </gml:Surface>
       </sf:geometryProperty>
       <sf:observation uom="http://www.bipm.fr/en/si/derived_units/density">2\.63E3</sf:observation>
       <sf:typeCode codeSpace="https://www.dgiwg.org/FAD">DB160</sf:typeCode>
       <sf:b64BinaryProperty mimeType="text/plain">
       VHdhcyBicmlsbGlnLCBhbmQgdGhlIHNsaXRoeSB0b3Zlcw==
       </sf:b64BinaryProperty>
       <sf:reference xlink:type="simple" xlink:href="#f102"
xlink:role="http://cite.opengeospatial.org/gmlsf/ComplexGeoFeature" />
       <sf:auditTrail>
         <sf:Event>
           <sf:action>Insert</sf:action>
           <sf:timestamp>2006-10-21T11:28:00+01:00</sf:timestamp>
           <sf:userid>Axel.Lidenbrock</sf:userid>
         </sf:Event>
       </sf:auditTrail>
     </sf:ComplexGeoFeature>
   </sf:featureMember>
</sf:SimpleFeatureCollection>

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

Rob_Atkinson1 · October 13, 2009, 9:14pm

Note this is a very specific test of a particula aspect,

The four basics of GML simple features level 2 profiles we dont support yet are
1) inheritance of feature types (= attribnutes from multiple namespaces)
2) ability to xlink to reference element values instead of embedded
inline encodings
3) user defined complex types
4) multi-valued attributes

Funky geometry types is in fact the only difference between complex
and simple features profile level 2, so I guess the test is accurate
enough, but not particularly interesting to us compared to SF Level 2
support)

we support all of these with app-schema (though to be hoinest only
partially, until we fix GT2505 and the encoding issues its stopping us
fixing), Geoserver previously only supported a limited subset of Level
0, which allows 1&2 )

From what I have seen INSPIRE pretty much seems to use GML Level 2

profile in practice, though it doesnt deliberately limit itself.

Rob

On Tue, Oct 13, 2009 at 8:41 PM, Andrea Aime <aaime@anonymised.com> wrote:

Ben Caradoc-Davies ha scritto:

On 12/10/09 23:07, Chris Holmes wrote:

One thing that would be a nice target for app-schema though is the
'complex feature' tests. GeoServer has never passed them, but
app-schema opens the possibility. I think they're actually pretty basic
once the app-schema infrastructure is there. Has the app-schema team
checked them out? It's a check box when you run the tests.

I have seen the check box, but we have not looked at the tests.

It would be good to have a comprehensive CITE complex feature test data
set and tests. I have mentioned this to some contacts in the right
places, who are in agreement, but as yet I have not received a response.
There is a prospect on the medium term horizon that the GeoSciML
community will provide a test data set. We might be able to get this
adopted as the CITE complex feature test data set.

That sounds good, but also quite a bit of work.

I quite a quick peek at the complex data required for wfs 1.1 and the
origin dataset is attached at the end of this mail. Does not look
earth shattering, the only thing is that they are using Curve
and Surface, but in fact both of them are really equivalents of
multi linestrings and multi polygons... Did not look at the requests,
but maybe passing the existing cite tests is not that hard.

Cheers
Andrea

<?xml version="1.0" encoding="UTF-8"?>
<sf:SimpleFeatureCollection gml:id="f100"
xmlns:gml="http://www.opengis.net/gml"
xmlns:sf="http://cite.opengeospatial.org/gmlsf"
xmlns:xlink="http://www.w3.org/1999/xlink">

<gml:description>
Test data for assessing compliance with the GMLSF profile at level SF-1.
</gml:description>
<gml:name>CITE/WFS-1.1</gml:name>
<gml:boundedBy>
<gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">
<gml:lowerCorner>34.94 -10.52</gml:lowerCorner>
<gml:upperCorner>71.96 32.19</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>

<sf:featureMember>
<sf:ComplexGeoFeature gml:id="f101">
<gml:description>
Aliquam sed lorem. Nam non risus ut felis pellentesque consequat.
Curabitur
pede. Suspendisse potenti. Mauris lacinia. Donec risus leo,
luctus at,
aliquet vel, congue in, mi. Mauris pulvinar mollis felis. Etiam
posuere,
ante et luctus blandit, purus metus sollicitudin nisl, eget
gravida lorem
elit sed pede. Nunc tristique elementum sem. Nullam feugiat
mauris quis
tellus. Nulla cursus augue at ipsum. Mauris volutpat posuere
tellus. Quisque
accumsan tellus sit amet elit. Nam tempor libero id urna. Donec
ac sapien.
Class aptent taciti sociosqu ad litora torquent per conubia
nostra, per
inceptos hymenaeos. Ut sollicitudin dapibus magna. Phasellus erat
turpis,
adipiscing eu, lobortis ut, convallis a, nisl. Vivamus rutrum
magna eget
metus consectetuer ultrices. Sed ac nisi tincidunt risus euismod
condimentum.
</gml:description>
<gml:name
codeSpace="http://cite.opengeospatial.org/gmlsf">name\-f101</gml:name>
<sf:geometryProperty>
<gml:LineString srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4979">
<gml:posList>46.074 9.799 600.2 46.652 10.466 781.4</gml:posList>
</gml:LineString>
</sf:geometryProperty>
<sf:observation
uom="http://www.bipm.fr/en/si/derived_units/Celsius">2\.4</sf:observation>
<sf:typeCode
codeSpace="https://www.dgiwg.org/FAD">AQ064</sf:typeCode>
<sf:auditTrail>
<sf:Event>
<sf:action>Insert</sf:action>
<sf:timestamp>2006-06-29T12:37:00+02:00</sf:timestamp>
<sf:userid>Phineas.Fogg</sf:userid>
</sf:Event>
<sf:Event>
<sf:action>Update</sf:action>
<sf:timestamp>2006-06-30T10:37:00+02:00</sf:timestamp>
<sf:userid>Phineas.Fogg</sf:userid>
</sf:Event>
<sf:Event>
<sf:action>Update</sf:action>
<sf:timestamp>2006-06-30T16:07:00+02:00</sf:timestamp>
<sf:userid>Axel.Lidenbrock</sf:userid>
</sf:Event>
<sf:Event>
<sf:action>Update</sf:action>
<sf:timestamp>2006-07-12T16:16:00+02:00</sf:timestamp>
<sf:userid>Axel.Lidenbrock</sf:userid>
</sf:Event>
<sf:Event>
<sf:action>Update</sf:action>
<sf:timestamp>2006-09-06T09:47:07Z</sf:timestamp>
<sf:userid>Eugène.Rastignac</sf:userid>
</sf:Event>
</sf:auditTrail>
</sf:ComplexGeoFeature>
</sf:featureMember>

<sf:featureMember>
<sf:ComplexGeoFeature gml:id="f102">
<gml:description>
Integer euismod risus. Class aptent taciti sociosqu ad litora
torquent per
conubia nostra, per inceptos hymenaeos. Phasellus nec risus.
</gml:description>
<gml:name
codeSpace="http://cite.opengeospatial.org/gmlsf">name\-f102</gml:name>
<gml:name>Vivamus blandit</gml:name>
<sf:geometryProperty>
<gml:Curve srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4979">
<gml:segments>
<gml:LineStringSegment interpolation="linear">
<gml:posList>45.174 2.899 45.652 2.466 45.891
2.899</gml:posList>
</gml:LineStringSegment>
<gml:LineStringSegment interpolation="linear">
<gml:posList>45.891 2.899 48.174 2.899 48.652 2.466
48.891 2.899</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</sf:geometryProperty>
<sf:observation
uom="http://www.bipm.fr/en/si/si_brochure/chapter2/2-1/metre.html">14\.1</sf:observation>
<sf:typeCode
codeSpace="https://www.dgiwg.org/FAD">SA060</sf:typeCode>
<sf:auditTrail>
<sf:Event>
<sf:action>Insert</sf:action>
<sf:timestamp>2006-10-21T11:28:00+01:00</sf:timestamp>
<sf:userid>Axel.Lidenbrock</sf:userid>
</sf:Event>
<sf:Event>
<sf:action>Update</sf:action>
<sf:timestamp>2006-10-30T21:05:00+01:00</sf:timestamp>
<sf:userid>Phineas.Fogg</sf:userid>
</sf:Event>
</sf:auditTrail>
</sf:ComplexGeoFeature>
</sf:featureMember>

<sf:featureMember>
<sf:ComplexGeoFeature gml:id="f103">
<gml:name
codeSpace="http://cite.opengeospatial.org/gmlsf">name\-f103</gml:name>
<sf:geometryProperty>
<gml:Surface srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">
<gml:patches>
<gml:PolygonPatch interpolation="planar">
<gml:exterior>
<gml:LinearRing>
<gml:posList>37.5 6.0 37.5 8.0 40.0 8.0 40.0 6.0 37.5
6.0</gml:posList>
</gml:LinearRing>
</gml:exterior>
<gml:interior>
<gml:LinearRing>
<gml:posList>38.0 6.5 39.0 6.5 39.0 7.0 38.0
6.5</gml:posList>
</gml:LinearRing>
</gml:interior>
</gml:PolygonPatch>
<gml:PolygonPatch interpolation="planar">
<gml:exterior>
<gml:LinearRing>
<gml:posList>40.0 6.0 40.0 8.0 42.5 9.0 42.5 5.0 40.0
6.0</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</sf:geometryProperty>
<sf:observation
uom="http://www.bipm.fr/en/si/derived_units/density">2\.63E3</sf:observation>
<sf:typeCode
codeSpace="https://www.dgiwg.org/FAD">DB160</sf:typeCode>
<sf:b64BinaryProperty mimeType="text/plain">
VHdhcyBicmlsbGlnLCBhbmQgdGhlIHNsaXRoeSB0b3Zlcw==
</sf:b64BinaryProperty>
<sf:reference xlink:type="simple" xlink:href="#f102"

xlink:role="http://cite.opengeospatial.org/gmlsf/ComplexGeoFeature" />
<sf:auditTrail>
<sf:Event>
<sf:action>Insert</sf:action>
<sf:timestamp>2006-10-21T11:28:00+01:00</sf:timestamp>
<sf:userid>Axel.Lidenbrock</sf:userid>
</sf:Event>
</sf:auditTrail>
</sf:ComplexGeoFeature>
</sf:featureMember>
</sf:SimpleFeatureCollection>

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel