[Geoserver-devel] Validation off in GML parsing on trunk?

Hi,
today I was trying to check an issue for a user and run the following
transaction:

<wfs:Transaction service="WFS" version="1.0.0"
   xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:topp="http://www.openplans.org/topp&quot;
   xmlns:gml="http://www.opengis.net/gml&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-transaction.xsd http://www.openplans.org/topp http://localhost:8080/geoserver/wfs/DescribeFeatureType?typename=topp:sightings&quot;&gt;
   <wfs:Insert>
     <topp:sightings>
      <topp:description>Hey there</topp:description>
       <topp:geom>
            <gml:coordinates>10,10</gml:coordinates>
       </topp:geom>
     </topp:sightings>
   </wfs:Insert>
</wfs:Transaction>

Well, it's what I wrote in the GeoServer sample requests dialog.
I did not expect it to work first time, instead
much to my surprise it did. So I checked on the db and saw that
a record was added but without the two specified fields.
Now, the above transaction is wrong in two ways:
* there is no description field in the feature type, the field
   is named "species" instead
* the point specification is wrong, it should be
   <topp:geom><gml:Point><gml:coordinates>...

Yet, the parser did not complain and I had to double check on the
database to notice. This is not good, since the
above document is not valid from a schema point of view...
how comes the validation is (apparently) turned off?
For the record, the describe feature type called to retrieve
the schema works and returns the following schema:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:gml="http://www.opengis.net/gml&quot; xmlns:topp="http://www.openplans.org/topp&quot; elementFormDefault="qualified" targetNamespace="http://www.openplans.org/topp&quot;&gt;
   <xsd:import namespace="http://www.opengis.net/gml&quot; schemaLocation="http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd&quot;/&gt;
   <xsd:complexType name="sightingsType">
     <xsd:complexContent>
       <xsd:extension base="gml:AbstractFeatureType">
         <xsd:sequence>
           <xsd:element maxOccurs="1" minOccurs="0" name="species" nillable="true" type="xsd:string"/>
           <xsd:element maxOccurs="1" minOccurs="0" name="geom" nillable="true" type="gml:PointPropertyType"/>
         </xsd:sequence>

       </xsd:extension>
     </xsd:complexContent>
   </xsd:complexType>
   <xsd:element name="sightings" substitutionGroup="gml:_Feature" type="topp:sightingsType"/>
</xsd:schema>

Running the same request against 1.5.4, which is using the old gml parser, returns the following error:

org.xml.sax.SAXException: Could not find attributeType named descriptionin featureType DefaultFeatureType [name=sightings , namespace=http://www.openplans.org/topp , abstract=false , types=(DefaultAttributeType [name=species , type=class java.lang.String , nillable=true, min=1, max=1],DefaultAttributeType [name=geom , type=class com.vividsolutions.jts.geom.Point , nillable=true, min=1, max=1],)]
org.xml.sax.SAXException: Could not find attributeType named descriptionin featureType DefaultFeatureType [name=sightings , namespace=http://www.openplans.org/topp , abstract=false , types=(DefaultAttributeType [name=species , type=class java.lang.String , nillable=true, min=1, max=1],DefaultAttributeType [name=geom , type=class com.vividsolutions.jts.geom.Point , nillable=true, min=1, max=1],)]

Cheers
Andrea

Andrea Aime ha scritto:

Yet, the parser did not complain and I had to double check on the
database to notice. This is not good, since the
above document is not valid from a schema point of view...
how comes the validation is (apparently) turned off?

A quick check in the source code seems to suggest all usages
of the new parser are non validating. In fact I've found
a parser.setValidating(true) only in wfs 1.1 and only if
the cite hacks are turned on... this does not look right to
me, the default behaviour should be the opposite, otherwise
figuring out one's errors in the xml becomes quite hard...
Opinions?
Cheers
Andrea

I think turning on xml validation is too strict. Many requests that did
work no problem for 1.5.x will cease to work.

As for making the parser more lax or more strict, its a tough call.
Recently I have done much to make the parser quite lax to handle many
bug reports which were regressions. But at the same time a case like
this illustrates the need for better error reporting.

Perhaps an alternative is to do more checking in the operation itself
like we do in get feature for instance, when checking property names
used in filters.

-Justin

Andrea Aime wrote:

Andrea Aime ha scritto:

Yet, the parser did not complain and I had to double check on the
database to notice. This is not good, since the
above document is not valid from a schema point of view...
how comes the validation is (apparently) turned off?

A quick check in the source code seems to suggest all usages
of the new parser are non validating. In fact I've found
a parser.setValidating(true) only in wfs 1.1 and only if
the cite hacks are turned on... this does not look right to
me, the default behaviour should be the opposite, otherwise
figuring out one's errors in the xml becomes quite hard...
Opinions?
Cheers
Andrea

-------------------------------------------------------------------------
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,47387f70185801015089218!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira ha scritto:

I think turning on xml validation is too strict. Many requests that did
work no problem for 1.5.x will cease to work.

As for making the parser more lax or more strict, its a tough call.
Recently I have done much to make the parser quite lax to handle many
bug reports which were regressions. But at the same time a case like
this illustrates the need for better error reporting.

Perhaps an alternative is to do more checking in the operation itself
like we do in get feature for instance, when checking property names
used in filters.

I don't know... in this case it's a request that had correct error
reporting on 1.5.x and does not have any on trunk. After the fact checks
may not be working... won't the parser just drop "description" because
it's not part of the feature type? (being the parser driven by the
schema)?

Cheers
Andrea

I don't know... in this case it's a request that had correct error
reporting on 1.5.x and does not have any on trunk. After the fact checks
may not be working... won't the parser just drop "description" because
it's not part of the feature type? (being the parser driven by the
schema)?

Well... being defined on the abstract gml feature type it is part of the
schema. However this should have no effect unless the user actually
declares a column named "description". What happened in this case? Was
the species column set to the description specified?

Cheers
Andrea

-------------------------------------------------------------------------
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,4738b7ae8753327367457!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira ha scritto:

I don't know... in this case it's a request that had correct error
reporting on 1.5.x and does not have any on trunk. After the fact checks
may not be working... won't the parser just drop "description" because
it's not part of the feature type? (being the parser driven by the
schema)?

Well... being defined on the abstract gml feature type it is part of the
schema. However this should have no effect unless the user actually
declares a column named "description". What happened in this case? Was
the species column set to the description specified?

No no, nothing happened, a null was placed in it... but besides description, also the geometry was not read and there were no
complaints. So you say if I stated "xxx" instead of description
I should have got back an exception? (a "TooHotFieldException"
maybe :-p)

Cheers
Andrea