We decided to interpret type names belonging to the request default namespace and not found as a geoserver type name as being in the GeoServer's default namespace, only if full cite conformance is not enabled.
Full history:
> 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
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
Bug
Closed
Major
We decided to interpret type names belonging to the request default namespace and not found as a geoserver type name as being in the GeoServer's default namespace, only if full cite conformance is not enabled.
Full history:
> 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
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