[Geoserver-users] WFS GetFeature Post Request

Hi,

By reading the WFS 1.1.0 standard with whole lot of examples with underscores in the names and also by comparing the schema of DescribeFeatureType which defines the typeName to be xsd:QName this feels like a bug in the standard. And we have loads of WFS layers which have been in production for 6 years and which have underscores in the names. If GeoServer now does not accept those I would call it as depreciation.

WFS 2.0.0 refers to FES 2.0 http://docs.opengeospatial.org/is/09-026r2/09-026r2.html which makes it clear:

“typeNames parameter

The mandatory typeNames parameter shall be used within an ad hoc query expression to encode the names of one or more correlated resource types to be queried. Individual resource type names shall be encoded as QName (as given in W3C XML Schema Part 2).”

Now what is unclear is WFS 1.1.0 which says that underscores are NOT OK in query but they are OK for example in DescribeFeatureType

This is about DescribeFeatureType schema in WFS 1.1.0:

“A DescribeFeatureType element contains zero or more TypeName elements that encode the names of feature types that are to be described. If the content of the DescribeFeatureType element is empty, then that shall be interpreted as requesting a description of all feature types that a WFS can service. The following XML Schema fragment defines the XML encoding of a DescribeFeatureType request:

<xsd:element name=“DescribeFeatureType” type=“wfs:DescribeFeatureTypeType”/>

<xsd:complexType name=“DescribeFeatureTypeType”>

xsd:complexContent

<xsd:extension base=“wfs:BaseRequestType”>

xsd:sequence

<xsd:element name=“TypeName” type=“xsd:QName”

minOccurs=“0” maxOccurs=“unbounded”/>

</xsd:sequence>

<xsd:attribute name=“outputFormat”

type=“xsd:string” use=“optional”

default=“text/xml; subtype=gml/3.1.1”/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

-Jukka Rahkonen-

···

Andrea Aime wrote:

On Wed, Nov 5, 2014 at 1:30 PM, Rahkonen Jukka (Tike) <jukka.rahkonen@…486…> wrote:

Hi,

Where does the requirement not to accept underscore come from? I have been thinking that the WFS 1.1.0 schema presents QName leads to NCName with a possible prefix

In the Query typeName is not defined as NCName, but as TypeNameListType:

<xsd:attribute name=“typeName” type=“wfs:TypeNameListType” use=“required”>

xsd:annotation

xsd:documentation

The typeName attribute is a list of one or more feature type names that indicate which types of feature instances should be included in the reponse set. Specifying more than one typename indicates that a join operation is being performed. All the names in the typeName list must be valid types that belong to this query’s feature content as defined by the GML Application Schema.

</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

<xsd:simpleType name=“TypeNameListType”>

<xsd:restriction base=“wfs:Base_TypeNameListType”>

<xsd:pattern value=“((\w:)?\w(=\w)?){1,}”>

xsd:annotation

xsd:documentation

Example typeName attribute value might be: typeName=“ns1:Inwatera_1m=A, ns2:CoastL_1M=B” In this example, A is an alias for ns1:Inwatera_1m and B is an alias for ns2:CoastL_1M.

</xsd:documentation>

</xsd:annotation>

</xsd:pattern>

</xsd:restriction>

</xsd:simpleType>

The funny thing is that the documentation uses _, but then again the XML validators do not accept it,

and the moment I removed it, the validation of the document passed.

So, I have to assume that \w does not include “_” as a valid char.

According to some docs I’ve found on the internet \w is defined as:

“Any character that might appear in a word. A shortcut for ‘[#X0000-#x10FFFF]-[\p{P}\p{Z}\p{C}]’ (all characters except the set of “punctuation”, “separator”, and “other” characters).”

I guess _ might be seen as a separator?

I’ve also tried to use “ns1:Inwatera_1m=A, ns2:CoastL_1M=B” in a GetFeature, and I cannot find a way to fix it,

which is not surprising, since WFS 1.1 does not support joining to start with…

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


On Wed, Nov 5, 2014 at 3:32 PM, Rahkonen Jukka (Tike) <
jukka.rahkonen@anonymised.com> wrote:

Hi,

By reading the WFS 1.1.0 standard with whole lot of examples with
underscores in the names and also by comparing the schema of
DescribeFeatureType which defines the typeName to be xsd:QName this feels
like a bug in the standard. And we have loads of WFS layers which have been
in production for 6 years and which have underscores in the names. If
GeoServer now does not accept those I would call it as depreciation.

Nothing changed. I believe our Stephan enabled scrict CITE compliance in
the WFS panel,
and that enables XML schema validation of all incoming requests, which
results in this error.

WFS 2.0.0 refers to FES 2.0
http://docs.opengeospatial.org/is/09-026r2/09-026r2.html which makes it
clear:

“typeNames parameter

The mandatory typeNames parameter shall be used within an ad hoc query
expression to encode the names of one or more correlated resource types to
be queried. Individual resource type names shall be encoded as QName (as
given in W3C XML Schema Part 2).”

I haven't tried, but I'm almost sure you won't see that error if you use
WFS 2.0

Now what is unclear is WFS 1.1.0 which says that underscores are NOT OK in
query but they are OK for example in DescribeFeatureType

Forget the specification, it's the XML schema that matters here :slight_smile:

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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