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:extension base=“wfs:BaseRequestType”>
<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”>
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,}”>
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://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.