On 17/12/2010, at 4:29 AM, Gabriel Roldán wrote: > 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.
Niels sent me a private email that the PropertyName api should be changed to match (so the filter can be copied for example; right now that is done by casting down to AttributeImpl or something). The only other reason I am tempted to go with Query.setNamespaceContext is that it would avoid cutting loose geoapi right now; and let us get this done sooner. Jody ------------------------------------------------------------------------------ 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
