Hey all,
In the wfs.xsd schema (cannonical, unfortunately, as it's from
schemas.opengis.net), there's regex restriction on what can appear in the
'typeName' attribute on a WFS query. Like this:
<GetFeature ...>
<Query typeName='namespace:SCHEMA.TABLE_NAME'>
....
</Query>
</GetFeature>
The regex is this:
<xsd:pattern value="((\w:)?\w(=\w)?){1,}">
Unfortunately, this means that you're only allowed to use '\w' characters in
both the SCHEMA and TABLE_NAME parts of the string. This is limiting, as we
use 'dot' (.) and 'underscore' (_) a lot, but they aren't a part of the '\w'
class.
I propose we supply a slightly modified wfs.xsd schema with the above line
changed to:
<xsd:pattern value="((\w:)?[\w_.](=[\w_.])?){1,}">
for the purposes of having XML that actually validates our real requests.
Thoughts? It's another case of 'geoserver schemas diverge from OGC schemas'
but only in that we allow slightly more typeNames...no difference in infoset
model.
--saul
--
View this message in context: http://www.nabble.com/wfs.xsd-schema-for-WFS-1.1.0-tf4685063.html#a13388276
Sent from the GeoServer - Dev mailing list archive at Nabble.com.
That sounds like a horrible idea 
Some of the cascading WFS code is built up on the idea the type names are going to be "good' in the sense of that regex you describe; if you start messing with things and returning invalid names I am going to be in a world of hurt.
Saul there should be a separation between your raw table name and the content you are serving up; since you need results rather than questions why not handle this another way:
- make a namespace for each schema, an easy way would be to place the database schema as aprt of your namespace url. Something like: http://my.server.com:8080:/somepath/SCHEMA:TABLE_NAME
Cheers,
Jody
sfarber wrote:
Hey all,
In the wfs.xsd schema (cannonical, unfortunately, as it's from
schemas.opengis.net), there's regex restriction on what can appear in the
'typeName' attribute on a WFS query. Like this:
<GetFeature ...>
<Query typeName='namespace:SCHEMA.TABLE_NAME'>
....
</Query>
</GetFeature>
The regex is this:
<xsd:pattern value="((\w:)?\w(=\w)?){1,}">
Unfortunately, this means that you're only allowed to use '\w' characters in
both the SCHEMA and TABLE_NAME parts of the string. This is limiting, as we
use 'dot' (.) and 'underscore' (_) a lot, but they aren't a part of the '\w'
class.
I propose we supply a slightly modified wfs.xsd schema with the above line
changed to:
<xsd:pattern value="((\w:)?[\w_.](=[\w_.])?){1,}">
for the purposes of having XML that actually validates our real requests.
Thoughts? It's another case of 'geoserver schemas diverge from OGC schemas'
but only in that we allow slightly more typeNames...no difference in infoset
model.
--saul
Hi Saul,
Yes, this is a pain. I brought this up on the wfs-devel list but got no
response. As for hacking the schema ourselves we could probably pull it
off. I don't think there are cite tests that pass this case.
However, this should only affect us in cases where cite compliance is
turned on, since schema validation is turned on. But i guess any other
code that attempts to validate will run into the same problem.
-Justin
sfarber wrote:
Hey all,
In the wfs.xsd schema (cannonical, unfortunately, as it's from
schemas.opengis.net), there's regex restriction on what can appear in the
'typeName' attribute on a WFS query. Like this:
<GetFeature ...>
<Query typeName='namespace:SCHEMA.TABLE_NAME'>
....
</Query>
</GetFeature>
The regex is this:
<xsd:pattern value="((\w:)?\w(=\w)?){1,}">
Unfortunately, this means that you're only allowed to use '\w' characters in
both the SCHEMA and TABLE_NAME parts of the string. This is limiting, as we
use 'dot' (.) and 'underscore' (_) a lot, but they aren't a part of the '\w'
class.
I propose we supply a slightly modified wfs.xsd schema with the above line
changed to:
<xsd:pattern value="((\w:)?[\w_.](=[\w_.])?){1,}">
for the purposes of having XML that actually validates our real requests.
Thoughts? It's another case of 'geoserver schemas diverge from OGC schemas'
but only in that we allow slightly more typeNames...no difference in infoset
model.
--saul
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Yeah, that's my problem exactly. I've got an "XML firewall" between the
clients and geoserver, and the "XML firewall" wants to validate all
incoming requests.
What are your thoughts re: jody's response?
Is there a chance we could banish the characters '.' and "_" from all
featuretype names? I'm thinking that would be an inordinate amount of
work...
--saul
On Wed, 2007-10-24 at 11:56 -0700, Justin Deoliveira wrote:
Hi Saul,
Yes, this is a pain. I brought this up on the wfs-devel list but got no
response. As for hacking the schema ourselves we could probably pull it
off. I don't think there are cite tests that pass this case.
However, this should only affect us in cases where cite compliance is
turned on, since schema validation is turned on. But i guess any other
code that attempts to validate will run into the same problem.
-Justin
sfarber wrote:
> Hey all,
>
> In the wfs.xsd schema (cannonical, unfortunately, as it's from
> schemas.opengis.net), there's regex restriction on what can appear in the
> 'typeName' attribute on a WFS query. Like this:
>
> <GetFeature ...>
> <Query typeName='namespace:SCHEMA.TABLE_NAME'>
> ....
> </Query>
> </GetFeature>
>
> The regex is this:
>
> <xsd:pattern value="((\w:)?\w(=\w)?){1,}">
>
> Unfortunately, this means that you're only allowed to use '\w' characters in
> both the SCHEMA and TABLE_NAME parts of the string. This is limiting, as we
> use 'dot' (.) and 'underscore' (_) a lot, but they aren't a part of the '\w'
> class.
>
> I propose we supply a slightly modified wfs.xsd schema with the above line
> changed to:
>
> <xsd:pattern value="((\w:)?[\w_.](=[\w_.])?){1,}">
>
> for the purposes of having XML that actually validates our real requests.
>
> Thoughts? It's another case of 'geoserver schemas diverge from OGC schemas'
> but only in that we allow slightly more typeNames...no difference in infoset
> model.
>
> --saul
I think I get your point Jody. And it's a good one (stick to the
schemas, they're there for a reason!)
That said, you're saying that geoserver needs to forbid the characters
"." and "_" from any and all featuretype names starting with WFS 1.1.0.
That's a fairly tall order.
Any ideas about harmonizing these two facts? I'm thinking that
geoserver kinda got shafted by the WFS 1.1.0 spec (makes previously
valid typeNames invalid!) but I guess that's just the way it goes.
--saul
On Wed, 2007-10-24 at 11:35 -0700, Jody Garnett wrote:
That sounds like a horrible idea Some of the cascading WFS code is
built up on the idea the type names are going to be "good' in the sense
of that regex you describe; if you start messing with things and
returning invalid names I am going to be in a world of hurt.
Saul there should be a separation between your raw table name and the
content you are serving up; since you need results rather than questions
why not handle this another way:
- make a namespace for each schema, an easy way would be to place the
database schema as aprt of your namespace url. Something like:
http://my.server.com:8080:/somepath/SCHEMA:TABLE_NAME
Cheers,
Jody
sfarber wrote:
> Hey all,
>
> In the wfs.xsd schema (cannonical, unfortunately, as it's from
> schemas.opengis.net), there's regex restriction on what can appear in the
> 'typeName' attribute on a WFS query. Like this:
>
> <GetFeature ...>
> <Query typeName='namespace:SCHEMA.TABLE_NAME'>
> ....
> </Query>
> </GetFeature>
>
> The regex is this:
>
> <xsd:pattern value="((\w:)?\w(=\w)?){1,}">
>
> Unfortunately, this means that you're only allowed to use '\w' characters in
> both the SCHEMA and TABLE_NAME parts of the string. This is limiting, as we
> use 'dot' (.) and 'underscore' (_) a lot, but they aren't a part of the '\w'
> class.
>
> I propose we supply a slightly modified wfs.xsd schema with the above line
> changed to:
>
> <xsd:pattern value="((\w:)?[\w_.](=[\w_.])?){1,}">
>
> for the purposes of having XML that actually validates our real requests.
>
> Thoughts? It's another case of 'geoserver schemas diverge from OGC schemas'
> but only in that we allow slightly more typeNames...no difference in infoset
> model.
>
> --saul
>
To be honest I am not sure i understood it :). We don't have the ability
to separate the underling table name from the name that is published so
this does not strike me as something we can do easily.
So I think we either tell wfs 1.1 users tough, you cant have underscores
in your table names, or hack the schema. In my opinion the amount of
cases where people have an "_" in a table name will far outweigh the
number of cases where people are actually validating wfs feature type names.
-Justin
Saul Farber wrote:
Yeah, that's my problem exactly. I've got an "XML firewall" between the
clients and geoserver, and the "XML firewall" wants to validate all
incoming requests.
What are your thoughts re: jody's response?
Is there a chance we could banish the characters '.' and "_" from all
featuretype names? I'm thinking that would be an inordinate amount of
work...
--saul
On Wed, 2007-10-24 at 11:56 -0700, Justin Deoliveira wrote:
Hi Saul,
Yes, this is a pain. I brought this up on the wfs-devel list but got no
response. As for hacking the schema ourselves we could probably pull it
off. I don't think there are cite tests that pass this case.
However, this should only affect us in cases where cite compliance is
turned on, since schema validation is turned on. But i guess any other
code that attempts to validate will run into the same problem.
-Justin
sfarber wrote:
Hey all,
In the wfs.xsd schema (cannonical, unfortunately, as it's from
schemas.opengis.net), there's regex restriction on what can appear in the
'typeName' attribute on a WFS query. Like this:
<GetFeature ...>
<Query typeName='namespace:SCHEMA.TABLE_NAME'>
....
</Query>
</GetFeature>
The regex is this:
<xsd:pattern value="((\w:)?\w(=\w)?){1,}">
Unfortunately, this means that you're only allowed to use '\w' characters in
both the SCHEMA and TABLE_NAME parts of the string. This is limiting, as we
use 'dot' (.) and 'underscore' (_) a lot, but they aren't a part of the '\w'
class.
I propose we supply a slightly modified wfs.xsd schema with the above line
changed to:
<xsd:pattern value="((\w:)?[\w_.](=[\w_.])?){1,}">
for the purposes of having XML that actually validates our real requests.
Thoughts? It's another case of 'geoserver schemas diverge from OGC schemas'
but only in that we allow slightly more typeNames...no difference in infoset
model.
--saul
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,471f974a316201012714783!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Saul Farber ha scritto:
Yeah, that's my problem exactly. I've got an "XML firewall" between the
clients and geoserver, and the "XML firewall" wants to validate all
incoming requests.
What are your thoughts re: jody's response?
Is there a chance we could banish the characters '.' and "_" from all
featuretype names? I'm thinking that would be an inordinate amount of
work...
Hmmm... way less than you think. At the moment we already have, in
GeoServer 1.6, a wrapping datastore that does exactly type name renaming.
I created it to allow GeoServer to be wfs cascadable, and at the
moment it just replaces ":" with "_" (but can be reconfigured
to just remove the namespace prefix from the type names we gather
cascading another GeoServer).
Extending it to strip out "_" and "." would be real easy.
Now, doing so in a way that preserves type name uniqueness is a
different story, and one I'm not sure we can tackle in any
simple way.
Think of the following case. A datastore has my_type and my.type.
We do rename the first into, say, mytype, but we cannot do the
same with my.type. So we call it, say, mytype1.
Then the user removes my_type from the storage and restarts
GeoServer. Now my.type becomes mytype, since there are no conflicts,
and from the external user point of view the type name changed!
If we can accept a behaviour such as complaining loudly when a
conflict arises (instead of trying to work around it), then
the solution is already inside GeoServer.
Let me know.
Cheers
Andrea