[Geoserver-devel] On xml and tests

GeoServer GeoServer Developer
1

Hi,
much of our (functional) test are based on a simple structure:
* make a get/post request
* parse the resulting xml
* validate the result/make some asserts on it

We use a mix of home grown utility methods and low level
dom access to make the checks on the xml. When making the
WCS 1.1.1 tests I was annoyed by how verbose direct
Dom access was and I started using XPath thru an utility
class provided by Xalan, this makes access to very nested
xml much more convinient (one line of code instead of,
say, 5-10 for each test).

Just yesterday I stumbled upon this junit extension that
allows for unit tests and has all of what we're using
packaged in a more convenient way:
http://xmlunit.sourceforge.net/
http://www.infoq.com/articles/xml-unit-test

The latest version can be effectively used in Java5 without
the need to use their base test class.
I'm probably going to remove Xalan test dependency from
WCS 1.1.1 and use XMLUnit instead. What do you think of
using it to power the rest of our xml testing needs?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4022,47a580ad233901804284693!

2

Hi there, just migrated from geoserver 1.5.4 trying out 1.6 r3..

there seems to be a problem with the following GetFeature:

  <wfs:Query typeName="ntlis:CADASTRE" srsName="EPSG:4283" >
    <ogc:Filter>
        <ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\\">
          <ogc:PropertyName>ntlis:LAISKEY</ogc:PropertyName>
          <ogc:Literal>550 07683%</ogc:Literal>
        </ogc:PropertyIsLike>
    </ogc:Filter>
  </wfs:Query>

where the resulting oracle SQL according to the logs is:
SELECT "LAISKEY", ..(other attributes).., "GEOMETRY" FROM "CADASTRE"
WHERE UPPER("LAISKEY") LIKE UPPER('550 07683%')

notice the multiple spaces in the LAISKEY attribute have been dropped
off, resulting in no results returned.

i'm guessing this is a bug at the geotools end ? am i able to use an
older oracle data source with the new geoserver ?

thanks,

-ivan

-----Original Message-----
From: geoserver-devel-bounces@lists.sourceforge.net
[mailto:geoserver-devel-bounces@lists.sourceforge.net] On Behalf Of
Andrea Aime
Sent: Sunday, 3 February 2008 6:24 PM
To: Geoserver-devel
Subject: [Geoserver-devel] On xml and tests

Hi,
much of our (functional) test are based on a simple structure:
* make a get/post request
* parse the resulting xml
* validate the result/make some asserts on it

We use a mix of home grown utility methods and low level dom access to
make the checks on the xml. When making the WCS 1.1.1 tests I was
annoyed by how verbose direct Dom access was and I started using XPath
thru an utility class provided by Xalan, this makes access to very
nested xml much more convinient (one line of code instead of, say, 5-10
for each test).

Just yesterday I stumbled upon this junit extension that allows for unit
tests and has all of what we're using packaged in a more convenient way:
http://xmlunit.sourceforge.net/
http://www.infoq.com/articles/xml-unit-test

The latest version can be effectively used in Java5 without the need to
use their base test class.
I'm probably going to remove Xalan test dependency from WCS 1.1.1 and
use XMLUnit instead. What do you think of using it to power the rest of
our xml testing needs?

Cheers
Andrea

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4022,47a580ad233901804284693!

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Hi Andrea,

The convenience methods look really good. And believe me i know... i have written tones of annoying dom test code. XmlUnit looks good. One thing that kind of rubs me the wrong way is that our unit tests would have to extend from XmlTestCase, correct? This does not really make sense for tests which have nothing to do with xml. I know technically there is no issue since if you dont need the methods you dont have to use them, but there is something about it that just does not feel clean. I guess I would prefer a set of nice convenience methods available for test cases to call as they need them.

-Justin

Andrea Aime wrote:

Hi,
much of our (functional) test are based on a simple structure:
* make a get/post request
* parse the resulting xml
* validate the result/make some asserts on it

We use a mix of home grown utility methods and low level
dom access to make the checks on the xml. When making the
WCS 1.1.1 tests I was annoyed by how verbose direct
Dom access was and I started using XPath thru an utility
class provided by Xalan, this makes access to very nested
xml much more convinient (one line of code instead of,
say, 5-10 for each test).

Just yesterday I stumbled upon this junit extension that
allows for unit tests and has all of what we're using
packaged in a more convenient way:
http://xmlunit.sourceforge.net/
http://www.infoq.com/articles/xml-unit-test

The latest version can be effectively used in Java5 without
the need to use their base test class.
I'm probably going to remove Xalan test dependency from
WCS 1.1.1 and use XMLUnit instead. What do you think of
using it to power the rest of our xml testing needs?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47a5814b235253668746562!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

4

Justin Deoliveira ha scritto:

Hi Andrea,

The convenience methods look really good. And believe me i know... i have written tones of annoying dom test code. XmlUnit looks good. One thing that kind of rubs me the wrong way is that our unit tests would have to extend from XmlTestCase, correct? This does not really make sense for tests which have nothing to do with xml.

You just have to static import XAssert and you have the xml
assertions you need at your fingertips. From the user guide:

"The XMLAssert class provides the same set of assert...s as static methods. Use XMLAssert instead of XMLTestCase for your unit tests if you can't or don't want to inherit from XMLTestCase."

Cheers
Andrea

5

Andrea Aime ha scritto:

Justin Deoliveira ha scritto:

Hi Andrea,

The convenience methods look really good. And believe me i know... i have written tones of annoying dom test code. XmlUnit looks good. One thing that kind of rubs me the wrong way is that our unit tests would have to extend from XmlTestCase, correct? This does not really make sense for tests which have nothing to do with xml.

You just have to static import XAssert and you have the xml
assertions you need at your fingertips. From the user guide:

"The XMLAssert class provides the same set of assert...s as static methods. Use XMLAssert instead of XMLTestCase for your unit tests if you can't or don't want to inherit from XMLTestCase."

Soo, I went ahead and tried to use XMLUnit, and ended up with a mixed
bag of results... the look of the tests made with xmlunit is certainly
compelling:

Document doc = getAsDOM("wfs?request=GetFeature&typename=cdf:Fifteen"
+ "&version=1.0.0&service=wfs&maxFeatures=3&resultType=hits");
assertXpathEvaluatesTo("15", "/wfs:FeatureCollection/@numberOfFeatures", doc);

(the more complex the xpath, the better the comparison with code
that accesses the dom directly looks).

Yet, I've found a couple of drawbacks:
* when the xpath is wrong (syntactically) the result is an NPE...
   not very useful...
* xmlunit needs to be initialized with a namespace context in order
   to work with xml that uses namespaces. In the above case, the
   unit test initialization needs the following:

   Map<String, String> namespaces = new HashMap<String, String>();
   namespaces.put("wfs", "http://www.opengis.net/wfs&quot;\);
   XMLUnit.setXpathNamespaceContext(new SimpleNamespaceContext(namespaces));

Nothing earth shattering, but easy to forget. When this is not
there, the tests simply fails with the xpath being evaluated to...
a null node.

For comparison, here is a sample of the test code using Xalan in WCS 1.1:

Node identifier = XPathAPI.selectSingleNode(dom, "/wcs:CoverageDescriptions/wcs:CoverageDescription/wcs:Identifier");
assertEquals(layerId(WCSTestSupport.TASMANIA_DEM), identifier.getTextContent());

no namespace issues whatsoever. Xalan is certainly bigger, but it's
only a test dependency... yet I'm wondering if it conflict
with other xml related code during the tests. XMLUnit has the merit
of using the support built into the jdk.

Opinions? What do you prefer?
Cheers
Andrea

6

Cool, a big +1 from me then.

-Justin

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Andrea,

The convenience methods look really good. And believe me i know... i have written tones of annoying dom test code. XmlUnit looks good. One thing that kind of rubs me the wrong way is that our unit tests would have to extend from XmlTestCase, correct? This does not really make sense for tests which have nothing to do with xml.

You just have to static import XAssert and you have the xml
assertions you need at your fingertips. From the user guide:

"The XMLAssert class provides the same set of assert...s as static methods. Use XMLAssert instead of XMLTestCase for your unit tests if you can't or don't want to inherit from XMLTestCase."

Cheers
Andrea

!DSPAM:4007,47a8107220126491211187!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

7

Looks good. I am not sure which one i prefer one over the other. One thing I would like to do is mimic this for geotools xml testing... because if you think you see a lot of ugly dom code in geoserver you have not seen anything ;).

So just to sum up... both require a dependency with test scope? One with xalan, the other xmlunit. On the one hand it might be nice to have xalan around during testing to test the impact.

I would have to play with the api's myself to make a better determination. For now i will just trust your expert judgment :).

Andrea Aime wrote:

Andrea Aime ha scritto:

Justin Deoliveira ha scritto:

Hi Andrea,

The convenience methods look really good. And believe me i know... i have written tones of annoying dom test code. XmlUnit looks good. One thing that kind of rubs me the wrong way is that our unit tests would have to extend from XmlTestCase, correct? This does not really make sense for tests which have nothing to do with xml.

You just have to static import XAssert and you have the xml
assertions you need at your fingertips. From the user guide:

"The XMLAssert class provides the same set of assert...s as static methods. Use XMLAssert instead of XMLTestCase for your unit tests if you can't or don't want to inherit from XMLTestCase."

Soo, I went ahead and tried to use XMLUnit, and ended up with a mixed
bag of results... the look of the tests made with xmlunit is certainly
compelling:

Document doc = getAsDOM("wfs?request=GetFeature&typename=cdf:Fifteen"
+ "&version=1.0.0&service=wfs&maxFeatures=3&resultType=hits");
assertXpathEvaluatesTo("15", "/wfs:FeatureCollection/@numberOfFeatures", doc);

(the more complex the xpath, the better the comparison with code
that accesses the dom directly looks).

Yet, I've found a couple of drawbacks:
* when the xpath is wrong (syntactically) the result is an NPE...
   not very useful...
* xmlunit needs to be initialized with a namespace context in order
   to work with xml that uses namespaces. In the above case, the
   unit test initialization needs the following:

   Map<String, String> namespaces = new HashMap<String, String>();
   namespaces.put("wfs", "http://www.opengis.net/wfs&quot;\);
   XMLUnit.setXpathNamespaceContext(new SimpleNamespaceContext(namespaces));

Nothing earth shattering, but easy to forget. When this is not
there, the tests simply fails with the xpath being evaluated to...
a null node.

For comparison, here is a sample of the test code using Xalan in WCS 1.1:

Node identifier = XPathAPI.selectSingleNode(dom, "/wcs:CoverageDescriptions/wcs:CoverageDescription/wcs:Identifier");
assertEquals(layerId(WCSTestSupport.TASMANIA_DEM), identifier.getTextContent());

no namespace issues whatsoever. Xalan is certainly bigger, but it's
only a test dependency... yet I'm wondering if it conflict
with other xml related code during the tests. XMLUnit has the merit
of using the support built into the jdk.

Opinions? What do you prefer?
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47a86e7b120021137850744!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

8

Ivan Price ha scritto:

Hi there, just migrated from geoserver 1.5.4 trying out 1.6 r3..

there seems to be a problem with the following GetFeature:

  <wfs:Query typeName="ntlis:CADASTRE" srsName="EPSG:4283" >
    <ogc:Filter>
        <ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\\">
          <ogc:PropertyName>ntlis:LAISKEY</ogc:PropertyName>
          <ogc:Literal>550 07683%</ogc:Literal>
        </ogc:PropertyIsLike>
    </ogc:Filter>
  </wfs:Query>

where the resulting oracle SQL according to the logs is:
SELECT "LAISKEY", ..(other attributes).., "GEOMETRY" FROM "CADASTRE"
WHERE UPPER("LAISKEY") LIKE UPPER('550 07683%')

notice the multiple spaces in the LAISKEY attribute have been dropped
off, resulting in no results returned.

Justin, this is parsed by the xml-xsd parser right? Do you know if
the parser may be stripping the spaces?

i'm guessing this is a bug at the geotools end ? am i able to use an
older oracle data source with the new geoserver ?

An old oracle datastore simply won't work, they are binary incompatible.
Cheers
Andrea

9

Justin Deoliveira ha scritto:

Looks good. I am not sure which one i prefer one over the other. One thing I would like to do is mimic this for geotools xml testing... because if you think you see a lot of ugly dom code in geoserver you have not seen anything ;).

Hmm... or, I'll have a look if I feel then need to be scared :slight_smile:

So just to sum up... both require a dependency with test scope? One with xalan, the other xmlunit. On the one hand it might be nice to have xalan around during testing to test the impact.

Yes, in both cases just a test dependency.

I would have to play with the api's myself to make a better determination. For now i will just trust your expert judgment :).

Hmm... I'm lending towards xmlunit, since it has much more to offer (for example, xml validation, xml comparison based on the contents, see some
examples here: http://xmlunit.sourceforge.net/example.html).

Yet I guess somewhere we need
to stick a very big warning... hum... where? Developer guide?
Is there anything about unit testing?.

Cheers
Andrea

10

Justin, this is parsed by the xml-xsd parser right? Do you know if
the parser may be stripping the spaces?

Yes, the xml parser is collapsing the whitespace, and looking at the schema defition for Literal, it should be. If you examine the type hierachy of Literal, its whiteSpace facet has the value of "collapse", and not "preserve". From what I can tell only types that extend from "string" preserve whitespace.

I admit... that does not make sense for a "literal". Tough call. I could be reading something wrong... perhaps we should consult the filter spec writers on this one.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

11

OK thanks for that,

is there a workaround ? i'm happy to use soomething other than 'literal'
but looking through the specs i can't find an alternative.. literal is
always the container for the value.

Surely its not impossible to filter a layer using a value that contains
2 consecutive spaces ? can geoserver/geotools be tricked with some
character code or escaping to disguise the multiple spaces?

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, 6 February 2008 7:52 AM
To: Andrea Aime
Cc: Ivan Price; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Justin, this is parsed by the xml-xsd parser right? Do you know if the

parser may be stripping the spaces?

Yes, the xml parser is collapsing the whitespace, and looking at the
schema defition for Literal, it should be. If you examine the type
hierachy of Literal, its whiteSpace facet has the value of "collapse",
and not "preserve". From what I can tell only types that extend from
"string" preserve whitespace.

I admit... that does not make sense for a "literal". Tough call. I could
be reading something wrong... perhaps we should consult the filter spec
writers on this one.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

12

Yes, this seems silly to me as something you can not do either. But unless I am mis interpreting the specs wrong it does not seem so. I am going to send an email to the wfs mailing list and see what they have to say about this. I will let you know what I find.

-Justin

Ivan Price wrote:

OK thanks for that,

is there a workaround ? i'm happy to use soomething other than 'literal'
but looking through the specs i can't find an alternative.. literal is
always the container for the value.

Surely its not impossible to filter a layer using a value that contains
2 consecutive spaces ? can geoserver/geotools be tricked with some
character code or escaping to disguise the multiple spaces?

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com] Sent: Wednesday, 6 February 2008 7:52 AM
To: Andrea Aime
Cc: Ivan Price; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Justin, this is parsed by the xml-xsd parser right? Do you know if the

parser may be stripping the spaces?

Yes, the xml parser is collapsing the whitespace, and looking at the
schema defition for Literal, it should be. If you examine the type
hierachy of Literal, its whiteSpace facet has the value of "collapse",
and not "preserve". From what I can tell only types that extend from
"string" preserve whitespace.

I admit... that does not make sense for a "literal". Tough call. I could
be reading something wrong... perhaps we should consult the filter spec
writers on this one.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47a944a6139742092453641!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

13

Justin,

should i submit a bug for this one so it doesn't get lost ? i have come
up with a data hack to get by for now.. but think that at some time in
the future people should be able to do a filter honouring whitespace.

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, 6 February 2008 11:01 PM
To: Ivan Price
Cc: Andrea Aime; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Yes, this seems silly to me as something you can not do either. But
unless I am mis interpreting the specs wrong it does not seem so. I am
going to send an email to the wfs mailing list and see what they have to
say about this. I will let you know what I find.

-Justin

Ivan Price wrote:

OK thanks for that,

is there a workaround ? i'm happy to use soomething other than

'literal'

but looking through the specs i can't find an alternative.. literal is

always the container for the value.

Surely its not impossible to filter a layer using a value that
contains
2 consecutive spaces ? can geoserver/geotools be tricked with some
character code or escaping to disguise the multiple spaces?

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, 6 February 2008 7:52 AM
To: Andrea Aime
Cc: Ivan Price; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Justin, this is parsed by the xml-xsd parser right? Do you know if
the

parser may be stripping the spaces?

Yes, the xml parser is collapsing the whitespace, and looking at the
schema defition for Literal, it should be. If you examine the type
hierachy of Literal, its whiteSpace facet has the value of "collapse",

and not "preserve". From what I can tell only types that extend from
"string" preserve whitespace.

I admit... that does not make sense for a "literal". Tough call. I
could be reading something wrong... perhaps we should consult the
filter spec writers on this one.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

----------------------------------------------------------------------
--- This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47a944a6139742092453641!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

14

Justin Deoliveira ha scritto:

Justin, this is parsed by the xml-xsd parser right? Do you know if
the parser may be stripping the spaces?

Yes, the xml parser is collapsing the whitespace, and looking at the schema defition for Literal, it should be. If you examine the type hierachy of Literal, its whiteSpace facet has the value of "collapse", and not "preserve". From what I can tell only types that extend from "string" preserve whitespace.

Hem, Justin, I've looked into the schemas but I cannot find
any whitespace facet declaration in the Literal definition.
In this case, I guess the default should apply, but the w3c documentation is not very clear on this (at least to me):

"whiteSpace is applicable to all ·atomic· and ·list· datatypes. For all ·atomic· datatypes other than string (and types ·derived· by ·restriction· from it) the value of whiteSpace is collapse and cannot be changed by a schema author; for string the value of whiteSpace is preserve; for any type ·derived· by ·restriction· from string the value of whiteSpace can be any of the three legal values. For all datatypes ·derived· by ·list· the value of whiteSpace is collapse and cannot be changed by a schema author. For all datatypes ·derived· by ·union· whiteSpace does not apply directly; however, the normalization behavior of ·union· types is controlled by the value of whiteSpace on that one of the ·memberTypes· against which the ·union· is successfully validated."

Now, the Literal hierarchy is Literal -> LiteralType -> ExpressionType
-> ComplexType, which is nor atomic, nor list (right?).
A search on the internet does not make me much wiser, the only
sort of relevant document I found is this:
http://www.jenitennison.com/blog/node/43
but it does not match our case 1-1.

Ivan, out of curiosity, have you tried to specify your literal
using a CDATA? I think whitespace processing should be forbidden
in those? (again, not sure, I'm no xml expert).

Cheers
Andrea

15

"whiteSpace is applicable to all ·atomic· and ·list· datatypes. For all ·atomic· datatypes other than string (and types ·derived· by ·restriction· from it) the value of whiteSpace is collapse and cannot be changed by a schema author; for string the value of whiteSpace is preserve; for any type ·derived· by ·restriction· from string the value of whiteSpace can be any of the three legal values. For all datatypes ·derived· by ·list· the value of whiteSpace is collapse and cannot be changed by a schema author. For all datatypes ·derived· by ·union· whiteSpace does not apply directly; however, the normalization behavior of ·union· types is controlled by the value of whiteSpace on that one of the ·memberTypes· against which the ·union· is successfully validated."

Now, the Literal hierarchy is Literal -> LiteralType -> ExpressionType
-> ComplexType, which is nor atomic, nor list (right?).
A search on the internet does not make me much wiser, the only
sort of relevant document I found is this:
http://www.jenitennison.com/blog/node/43
but it does not match our case 1-1.

It is not quite clear to me either. From the spec it is not clear how a complex type with mixed content is supposed to be handled. The XSD library interprets such an entity to have whitespace = collapse... which is why the parser is doing what it is doing. I am not sure... I would liek to give ivan a way to solve his problem.

Ivan, out of curiosity, have you tried to specify your literal
using a CDATA? I think whitespace processing should be forbidden
in those? (again, not sure, I'm no xml expert).

Cheers
Andrea

!DSPAM:4007,47b2b1f1268141804284693!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

16

Hi Ivan,

Unfortunately we are not sure if this is a bug yet. The xml schema spec is not all that clear. I asked on the devel list... and someone suggested escaping the spaces. Which I think might have a decent chance of working. So I guess your literal would come out as:

"550 \\ \\ \\ \\ 07683%"

Or something. Perhaps you can try this option.

Ivan Price wrote:

Justin,

should i submit a bug for this one so it doesn't get lost ? i have come
up with a data hack to get by for now.. but think that at some time in
the future people should be able to do a filter honouring whitespace.

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com] Sent: Wednesday, 6 February 2008 11:01 PM
To: Ivan Price
Cc: Andrea Aime; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Yes, this seems silly to me as something you can not do either. But
unless I am mis interpreting the specs wrong it does not seem so. I am
going to send an email to the wfs mailing list and see what they have to
say about this. I will let you know what I find.

-Justin

Ivan Price wrote:

OK thanks for that,

is there a workaround ? i'm happy to use soomething other than

'literal'

but looking through the specs i can't find an alternative.. literal is

always the container for the value.

Surely its not impossible to filter a layer using a value that contains
2 consecutive spaces ? can geoserver/geotools be tricked with some character code or escaping to disguise the multiple spaces?

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, 6 February 2008 7:52 AM
To: Andrea Aime
Cc: Ivan Price; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an attribute filter..

Justin, this is parsed by the xml-xsd parser right? Do you know if the
parser may be stripping the spaces?

Yes, the xml parser is collapsing the whitespace, and looking at the schema defition for Literal, it should be. If you examine the type hierachy of Literal, its whiteSpace facet has the value of "collapse",

and not "preserve". From what I can tell only types that extend from "string" preserve whitespace.

I admit... that does not make sense for a "literal". Tough call. I could be reading something wrong... perhaps we should consult the filter spec writers on this one.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

----------------------------------------------------------------------
--- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

!DSPAM:4007,47b24c46162551804284693!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

17

Hi, thanks for this..

problem with the escape thing is that oracle doesn't seem to like an
attempt to escape anything other than a \ or a %.

so if i issue:

  <wfs:Query typeName="ntlis:CADASTRE">
    <ogc:Filter>
        <ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\">
          <ogc:PropertyName>ntlis:LAISKEY</ogc:PropertyName>
          <ogc:Literal>550 \\ \\ \\ \\ 04915%</ogc:Literal>
        </ogc:PropertyIsLike>
    </ogc:Filter>
  </wfs:Query>

the sql is:
SELECT blah,"GEOMETRY" FROM "CADASTRE" WHERE UPPER("LAISKEY") LIKE
UPPER('550 \\ \\ \\ \\ 04915%') ESCAPE '\'

which works fine (valid select query), but of course returns no results.
if i issue:

  <wfs:Query typeName="ntlis:CADASTRE">
    <ogc:Filter>
        <ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\">
          <ogc:PropertyName>ntlis:LAISKEY</ogc:PropertyName>
          <ogc:Literal>550 \ \ \ \ 04915%</ogc:Literal>
        </ogc:PropertyIsLike>
    </ogc:Filter>
  </wfs:Query>

oracle spits the dummy with:
(blah) WHERE UPPER("LAISKEY") LIKE UPPER('550 \ \ \ \ 04915%') ESCAPE
'\'
ORA-01424: missing or illegal character following the escape character

so i don't think i'm able to escape anything using an oracle datastore
other than \ or %.. at least at the data level.

Regarding the CDATA suggestion, Rob Atkinson suggested the same thing
directly to me.. unfortunately when i execute:
  <wfs:Query typeName="ntlis:CADASTRE">
    <ogc:Filter>
        <ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\">
          <ogc:PropertyName>ntlis:LAISKEY</ogc:PropertyName>
          <ogc:Literal><![CDATA[550 04915%]]></ogc:Literal>
        </ogc:PropertyIsLike>
    </ogc:Filter>
  </wfs:Query>

the resulting SQL is still:
SELECT blah,"GEOMETRY" FROM "CADASTRE" WHERE UPPER("LAISKEY") LIKE
UPPER('550 04915%')

not sure where that leaves us..

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Thursday, 14 February 2008 1:37 AM
To: Ivan Price
Cc: Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Hi Ivan,

Unfortunately we are not sure if this is a bug yet. The xml schema spec
is not all that clear. I asked on the devel list... and someone
suggested escaping the spaces. Which I think might have a decent chance
of working. So I guess your literal would come out as:

"550 \\ \\ \\ \\ 07683%"

Or something. Perhaps you can try this option.

Ivan Price wrote:

Justin,

should i submit a bug for this one so it doesn't get lost ? i have
come up with a data hack to get by for now.. but think that at some
time in the future people should be able to do a filter honouring

whitespace.

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, 6 February 2008 11:01 PM
To: Ivan Price
Cc: Andrea Aime; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Yes, this seems silly to me as something you can not do either. But
unless I am mis interpreting the specs wrong it does not seem so. I am

going to send an email to the wfs mailing list and see what they have
to say about this. I will let you know what I find.

-Justin

Ivan Price wrote:

OK thanks for that,

is there a workaround ? i'm happy to use soomething other than

'literal'

but looking through the specs i can't find an alternative.. literal
is

always the container for the value.

Surely its not impossible to filter a layer using a value that
contains
2 consecutive spaces ? can geoserver/geotools be tricked with some
character code or escaping to disguise the multiple spaces?

-i

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, 6 February 2008 7:52 AM
To: Andrea Aime
Cc: Ivan Price; Geoserver-devel
Subject: Re: [Geoserver-devel] problem with multiple spaces in an
attribute filter..

Justin, this is parsed by the xml-xsd parser right? Do you know if
the parser may be stripping the spaces?

Yes, the xml parser is collapsing the whitespace, and looking at the
schema defition for Literal, it should be. If you examine the type
hierachy of Literal, its whiteSpace facet has the value of
"collapse",

and not "preserve". From what I can tell only types that extend from
"string" preserve whitespace.

I admit... that does not make sense for a "literal". Tough call. I
could be reading something wrong... perhaps we should consult the
filter spec writers on this one.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

---------------------------------------------------------------------
-
--- This SF.net email is sponsored by: Microsoft Defy all challenges.

Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

!DSPAM:4007,47b24c46162551804284693!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com