Hey Andrea,

If you look on master and 8.x you will find this method actually already
exists in the ParserDelegate2 class. The canHandle there method looks like:

  boolean canHandle(QName elementName, Attributes attributes, Handler
handler, Handler parent);

And gives the full attributes. I think that should do the trick?

-Justin
On Fri, Jul 13, 2012 at 3:55 AM, Andrea Aime
<[email protected]>wrote:

> Hi,
> I'm getting in some trouble with parser delegates, trying to look for a
> solution.
>
> In WPS we have this thing were a WFS requet can be embedded in a WPS
> request
> to represent a input of the process.
> The whole XML is a single block and the parser traverses it directly using
> a mechanism
> called parser delegates, where the parsing configuration knows there might
> be some
> other elements, coming from other schemas, embedded in the main document.
>
> WPS in particular can delegate to a WFS 1.1 parser and a WCS 1.1 parser.
> However a WPS request can legitimately contain a WFS 2.0 or a WFS 1.0
> request too.
>
> I haven't tried, but believe that it would be easy to make it parse a WFS
> 2.0 embedded
> request because the parser delegate mechanism matches based on the
> target namespace, which is "http://www.opengis.net/wfs/2.0"; for WFS 2.0.
> Unfortunately it is the same, http://www.opengis.net/wfs, for both WFS
> 1.0 and WFS 1.1
> (big mistake, since the element names are the same).
>
> The two standards are close enough that we don't see much of a problem,
> but then
> we get into parsing a gml:Box, which exists only for GML 2.0 (used by WFS
> 1.0)
> and boom, the parsing fails (actually, a NPE happens later because the box
> was not parsed
> at all).
>
> What I was thinking that might solve the problem is to make canHandle
> method of
> XSDParser delegate get a full element object instead of a QName, so that
> it can also
> evaluate the version attribute: this way the WFS 1.1 could refuse to parse
> the
> WFS 1.0 request and leave the field open for the other parser
>
> Opinions?
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 962313
> mob:   +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to