Hi Justin,
working on the wfs 1.1 bindings and tests, got the following doubt:
The Delete element has a typeName attribute (as other requests do), yet,
though I've created the DeleleteElementType to encode and set the typeName
property with a QName ("http://www.openplans.org/topp", "TestType"), the
encoded xml element has no namespace prefix assigned, nor the namespace was
declared on the root element.
Followed the code until XSQNameTypeBinding calls
DatatypeConverter.printQName((QName) object, namespaceContext);
Yet I got lost looking for where the namespace context is set. So since I'm
pretty sure if the namespace context were set the QName would be correctly
encoded, though I don't see how to deal with it on the WFSTestSupport class?
Please take a look at the DeleteElementTypeBindingTest.testEncode method I
just commited.
cheers,
Gabriel.
Hi Gabriel,
You bring up a good issue. Currently the way the namespace prefixes are
serialized is that they are obtained directly from the XSDSchema object
the encoder is working from. As well as being serialized, they are also
put into a NamespaceContext object, which is available for bindings via
injection. And indeed this is what the XSQNameBinding does.
The problem is however that the wfs schema knows nothing of application
schema namespaces so there is no mapping in the namespace context, and
no prefix gets written out.
Ideally in a running system like GeoServer, an
ApplicationSchemaConfiguration would be used that would know about its
namespace so it would not be a problem. For testing purposes I suggest
we add a method to XMLTestSupport to quickly register a new prefix
namespace mapping.
What do you think?
Gabriel Roldán wrote:
Hi Justin,
working on the wfs 1.1 bindings and tests, got the following doubt:
The Delete element has a typeName attribute (as other requests do), yet,
though I've created the DeleleteElementType to encode and set the typeName
property with a QName ("http://www.openplans.org/topp", "TestType"), the
encoded xml element has no namespace prefix assigned, nor the namespace was
declared on the root element.
Followed the code until XSQNameTypeBinding calls
DatatypeConverter.printQName((QName) object, namespaceContext);
Yet I got lost looking for where the namespace context is set. So since I'm
pretty sure if the namespace context were set the QName would be correctly
encoded, though I don't see how to deal with it on the WFSTestSupport class?
Please take a look at the DeleteElementTypeBindingTest.testEncode method I
just commited.
cheers,
Gabriel.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,476eee2450261137850744!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Hi Justin,
yeah adding a facility at XMLTestSupport seems good as per the tests.
Yet, I've just seen your last commit exposing the encoder's namespace context.
It serves for the purpose, yet I'd prefer not to do so (exposing the internal
mutable state of the encoder), but adding the corresponding
registerNamespace(prefix, nsUri), getPrefix(nsUri), getNamespace(prefix), or
something like that to the Encoder interface.
does that make sense to you too?
cheers,
Gabriel
On Wednesday 26 December 2007 08:08:56 pm Justin Deoliveira wrote:
Hi Gabriel,
You bring up a good issue. Currently the way the namespace prefixes are
serialized is that they are obtained directly from the XSDSchema object
the encoder is working from. As well as being serialized, they are also
put into a NamespaceContext object, which is available for bindings via
injection. And indeed this is what the XSQNameBinding does.
The problem is however that the wfs schema knows nothing of application
schema namespaces so there is no mapping in the namespace context, and
no prefix gets written out.
Ideally in a running system like GeoServer, an
ApplicationSchemaConfiguration would be used that would know about its
namespace so it would not be a problem. For testing purposes I suggest
we add a method to XMLTestSupport to quickly register a new prefix
namespace mapping.
What do you think?
Gabriel Roldán wrote:
> Hi Justin,
>
> working on the wfs 1.1 bindings and tests, got the following doubt:
>
> The Delete element has a typeName attribute (as other requests do), yet,
> though I've created the DeleleteElementType to encode and set the
> typeName property with a QName ("http://www.openplans.org/topp",
> "TestType"), the encoded xml element has no namespace prefix assigned,
> nor the namespace was declared on the root element.
>
> Followed the code until XSQNameTypeBinding calls
> DatatypeConverter.printQName((QName) object, namespaceContext);
> Yet I got lost looking for where the namespace context is set. So since
> I'm pretty sure if the namespace context were set the QName would be
> correctly encoded, though I don't see how to deal with it on the
> WFSTestSupport class?
>
> Please take a look at the DeleteElementTypeBindingTest.testEncode method
> I just commited.
>
> cheers,
>
> Gabriel.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I see your point, and I agree. The rationale for adding this method to
the encoder was that the same method exists on the Parser, so its
consistent. Its also simpler than maintaining a seperate mapping and
copying it over :). Although that would not be complicated either.
However I dont have a strong preference one over the other.
-Justin
Gabriel Roldán wrote:
Hi Justin,
yeah adding a facility at XMLTestSupport seems good as per the tests.
Yet, I've just seen your last commit exposing the encoder's namespace context.
It serves for the purpose, yet I'd prefer not to do so (exposing the internal
mutable state of the encoder), but adding the corresponding
registerNamespace(prefix, nsUri), getPrefix(nsUri), getNamespace(prefix), or
something like that to the Encoder interface.
does that make sense to you too?
cheers,
Gabriel
On Wednesday 26 December 2007 08:08:56 pm Justin Deoliveira wrote:
Hi Gabriel,
You bring up a good issue. Currently the way the namespace prefixes are
serialized is that they are obtained directly from the XSDSchema object
the encoder is working from. As well as being serialized, they are also
put into a NamespaceContext object, which is available for bindings via
injection. And indeed this is what the XSQNameBinding does.
The problem is however that the wfs schema knows nothing of application
schema namespaces so there is no mapping in the namespace context, and
no prefix gets written out.
Ideally in a running system like GeoServer, an
ApplicationSchemaConfiguration would be used that would know about its
namespace so it would not be a problem. For testing purposes I suggest
we add a method to XMLTestSupport to quickly register a new prefix
namespace mapping.
What do you think?
Gabriel Roldán wrote:
Hi Justin,
working on the wfs 1.1 bindings and tests, got the following doubt:
The Delete element has a typeName attribute (as other requests do), yet,
though I've created the DeleleteElementType to encode and set the
typeName property with a QName ("http://www.openplans.org/topp",
"TestType"), the encoded xml element has no namespace prefix assigned,
nor the namespace was declared on the root element.
Followed the code until XSQNameTypeBinding calls
DatatypeConverter.printQName((QName) object, namespaceContext);
Yet I got lost looking for where the namespace context is set. So since
I'm pretty sure if the namespace context were set the QName would be
correctly encoded, though I don't see how to deal with it on the
WFSTestSupport class?
Please take a look at the DeleteElementTypeBindingTest.testEncode method
I just commited.
cheers,
Gabriel.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,4772c4d4268255332866982!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org