Hi,
I'm still debugging for this issue:
<http://jira.codehaus.org/browse/GEOS-1816>
The thing is, I don't think we should take the request as it is in that issue
as valid, since it is using an invalid type name.
What I mean is, if you don't want to use the namespace prefix in the TypeName
element, you should make the request default namespace the one of the feature
type you want. For instance, the following request do work:
Sorry, hit send accidentally, here it goes again:
Hi,
I'm still debugging for this issue:
<http://jira.codehaus.org/browse/GEOS-1816>
The thing is, I don't think we should take the request as it is in that
issue as valid, since it is using an invalid type name.
What I mean is, if you don't want to use the namespace prefix in the
TypeName element, you should make the request default namespace the one of
the feature type you want. For instance, the following request do work:
<wfs:DescribeFeatureType
version="1.0.0"
service="WFS"
xmlns:wfs="http://www.opengis.net/wfs"
xmlns="http://www.openplans.org/topp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd">
<wfs:TypeName>states</wfs:TypeName>
</wfs:DescribeFeatureType>
Now, the parser is doing a correct parse for the request, and using a request
body like the one in the issue parses the "states" type name in the request
default namespace, which is the wfs namespace.
So, do we still want to insert a hack to handle that?
I would say not, so I'm asking for more votes to take action in one direction
or the other.
regards,
Gabriel
Generally in cases like these, i will insert a "leniency hack" if we used to support the behavior, because technically its a regression.
I am also usually for being lenient with xml requests in general. But if there is strong opposition to this I could go either way.
-Justin
Gabriel Roldán wrote:
Sorry, hit send accidentally, here it goes again:
Hi,
I'm still debugging for this issue:
<http://jira.codehaus.org/browse/GEOS-1816>The thing is, I don't think we should take the request as it is in that
issue as valid, since it is using an invalid type name.What I mean is, if you don't want to use the namespace prefix in the
TypeName element, you should make the request default namespace the one of
the feature type you want. For instance, the following request do work:<wfs:DescribeFeatureType
version="1.0.0"
service="WFS"
xmlns:wfs="http://www.opengis.net/wfs"
xmlns="http://www.openplans.org/topp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd">
<wfs:TypeName>states</wfs:TypeName>
</wfs:DescribeFeatureType>Now, the parser is doing a correct parse for the request, and using a request body like the one in the issue parses the "states" type name in the request default namespace, which is the wfs namespace.
So, do we still want to insert a hack to handle that?
I would say not, so I'm asking for more votes to take action in one direction or the other.regards,
Gabriel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,47f391a425001012714783!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
On Wednesday 02 April 2008 04:54:47 pm Justin Deoliveira wrote:
Generally in cases like these, i will insert a "leniency hack" if we
used to support the behavior, because technically its a regression.
But you mean a "configurable" hack? like to enable it from the ui or
something? or just a silent hack?
I am also usually for being lenient with xml requests in general. But if
there is strong opposition to this I could go either way.
Not a strong opposition but a bad smell. Its a regression because we used to
be tolerant with the validity of the xml requests we received, or because we
used to be dumber at parsing?
It smells bad because that request is a valid xml, its just saying the
namespace for the "states" type is the request default one, so going through
the request and assuming that someone using the request default namespace for
the typename is wrong is a double edged knife...
Not sure I'm making my concern clear though...
Gabriel
-Justin
Gabriel Roldán wrote:
> Sorry, hit send accidentally, here it goes again:
>
> Hi,
>
> I'm still debugging for this issue:
> <http://jira.codehaus.org/browse/GEOS-1816>
>
> The thing is, I don't think we should take the request as it is in that
> issue as valid, since it is using an invalid type name.
>
> What I mean is, if you don't want to use the namespace prefix in the
> TypeName element, you should make the request default namespace the one
> of the feature type you want. For instance, the following request do
> work:
>
> <wfs:DescribeFeatureType
> version="1.0.0"
> service="WFS"
> xmlns:wfs="http://www.opengis.net/wfs"
> xmlns="http://www.openplans.org/topp"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.opengis.net/wfs
> http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd">
>
> <wfs:TypeName>states</wfs:TypeName>
>
> </wfs:DescribeFeatureType>
>
> Now, the parser is doing a correct parse for the request, and using a
> request body like the one in the issue parses the "states" type name in
> the request default namespace, which is the wfs namespace.
>
> So, do we still want to insert a hack to handle that?
> I would say not, so I'm asking for more votes to take action in one
> direction or the other.
>
> regards,
>
> Gabriel
>
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl
>ace _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Gabriel Roldán ha scritto:
On Wednesday 02 April 2008 04:54:47 pm Justin Deoliveira wrote:
Generally in cases like these, i will insert a "leniency hack" if we
used to support the behavior, because technically its a regression.But you mean a "configurable" hack? like to enable it from the ui or something? or just a silent hack?
I would like it as default behaviour, and become picky when the cite
hacks are turned on.
I am also usually for being lenient with xml requests in general. But if
there is strong opposition to this I could go either way.Not a strong opposition but a bad smell. Its a regression because we used to be tolerant with the validity of the xml requests we received, or because we used to be dumber at parsing?
It smells bad because that request is a valid xml, its just saying the namespace for the "states" type is the request default one, so going through the request and assuming that someone using the request default namespace for the typename is wrong is a double edged knife...
That's what we used to do, so we're breaking existing clients that were
coded against geoserver < 1.6.x (like udig). This is a regression in my book.
Also, how is it that the default namespace of xml elements gets inherited by the value of an element? Is this standard behaviour?
Cheers
Andrea
On Wednesday 02 April 2008 05:22:26 pm Andrea Aime wrote:
Gabriel Roldán ha scritto:
> On Wednesday 02 April 2008 04:54:47 pm Justin Deoliveira wrote:
>> Generally in cases like these, i will insert a "leniency hack" if we
>> used to support the behavior, because technically its a regression.
>
> But you mean a "configurable" hack? like to enable it from the ui or
> something? or just a silent hack?I would like it as default behaviour, and become picky when the cite
hacks are turned on.>> I am also usually for being lenient with xml requests in general. But if
>> there is strong opposition to this I could go either way.
>
> Not a strong opposition but a bad smell. Its a regression because we used
> to be tolerant with the validity of the xml requests we received, or
> because we used to be dumber at parsing?
> It smells bad because that request is a valid xml, its just saying the
> namespace for the "states" type is the request default one, so going
> through the request and assuming that someone using the request default
> namespace for the typename is wrong is a double edged knife...That's what we used to do, so we're breaking existing clients that were
coded against geoserver < 1.6.x (like udig). This is a regression in my
book.
This is a bug in previous versions of geoserver in mine 
Ok, lets do that as a hack for when cite compliance is not set so?
Also, how is it that the default namespace of xml elements gets
inherited by the value of an element?
Because the TypeName element is of QName type:
<xsd:complexType name="DescribeFeatureTypeType">
<xsd:complexContent>
<xsd:extension base="wfs:BaseRequestType">
<xsd:sequence>
<xsd:element name="TypeName" type="xsd:QName"
minOccurs="0" maxOccurs="unbounded">
Is this standard behaviour?
yup, quoting from <http://www.w3.org/TR/xmlschema-2/#QName>:
"The mapping between literals in the ·lexical space· and values in the ·value
space· of QName requires a namespace declaration to be in scope for the
context in which QName is used."
Cheers,
Gabriel
Cheers
Andrea!DSPAM:4045,47f3a4c970932090977483!
Gabriel Roldán ha scritto:
On Wednesday 02 April 2008 05:22:26 pm Andrea Aime wrote:
Gabriel Roldán ha scritto:
On Wednesday 02 April 2008 04:54:47 pm Justin Deoliveira wrote:
Generally in cases like these, i will insert a "leniency hack" if we
used to support the behavior, because technically its a regression.But you mean a "configurable" hack? like to enable it from the ui or
something? or just a silent hack?I would like it as default behaviour, and become picky when the cite
hacks are turned on.
When the cite hacks are turned on we give up any sloppiness and accept
only absolutely correct requests. By default we are lenient, we even
accept completely invalid xml, try it.
Cheers
Andrea