Question is whether we actually need Query.setNamespaceContext. I'm waiting on Niels for it, though I have the slight impression that we could live without it. But it's harder to get rid of it for Filter. Reasoning: - Query.setPropertyNames includes the requested property names, but there are practically no cases where prefix mapping for requested property names may be ambiguous. Even in the case of a POST GetFeature request that remaps the server published namespaces, you got the mappings and can as easily remap the prefixes to the ones the server knows about. - It may be the same for Filters whether or not inside an SLD. Difference being that in this case it is the (PropertyNames inside) Filter who needs to resolve the xpath, hence it needs to know about prefix mapping.
So I'm more inclined towards expanding the FilterFactory2 API if that single change would solve all the problems, which it seems like it will imho. 2c./ Gabriel On Thu, 2010-12-16 at 21:33 +1000, Jody Garnett wrote: > Hi Niels & Gabriel: > > > Can you review the following: > - http://docs.codehaus.org/display/GEOTOOLS/XPath+NamespaceSupport > > > I did have a bit of a second thought when prepping the code example: > > > NamespaceSupport namespaceSupport = new NamespaceSupport(); > namespaceSupport.declairPrefix("foo", "urn:cgi:xmlns:CGI:GeoSciML:2.0" ); > > FilterFactory2 ff = CommonFilterFactory.getFilterFactory2( null ); > Filter filter = > ff.greater(ff.property("foo:city/foo:size",namespaceSupport),ff.literal(300000)); > > FeatureCollection features = featureSource.getFeatures( filter ); > > > That all looks well and code; but when you add in the namespaceSupport > for Query: > > > Query query = new Query( typeName ); > query.setFilter( filter ); > query.setPropertyNames( new > String[]{"foo:x","foo:y","foo:description/foo:label"}); > query.setNamespaceSupport( namespaceSupport ); // defines the prefix foo > > > I am left with a question. > > > If we need query.setNamespaceSupport in order to handle the property > names; could we just use that (rather than making filter more > complicated?) The downside is of course Style; we would end up needing > a setNamespaceSupport for Style as well - in order to cover all the > filters and expressions mentioned. > > > Cheers, > Jody > > > On 15/12/2010, at 10:29 AM, Jody Garnett wrote: > > > Okay Gabriel took an hour to chat with me through ... I was hoping > > we could do more with xpath than the filter 1.1 spec allows us to. > > > > FilterFactory2 > > - FilterFactoryImplNamespaceAware ideas to be merged into > > FilterFactory2 (and thus part of our geotools api) > > - FilterFactory2.property( xpath, context ) > > > > "Context" > > - As for context; the implementation shows the Hint is made up of a > > single NamespaceSupport class. Since this is a SAX class it may be > > hard to use for people making up a context on the fly as part of a > > query? > > - Gabriel looked at NamespaceContext instead; but is having a hard > > time finding a good implementation > > > > Query: > > - getQueryHint should cover the use of a NamespaceSupport class as > > one of the hints; allowing propertyNames to work > > - or make an explicit Query.getNamespaceSupport() method to go with > > getPropertyNames() > > > > Neils I will send you our IRC chat. > > > > Jody > > > > > > > > -- Gabriel Roldan [email protected] Expert service straight from the developers ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
