I think you do need a NameSpace context in your query, because you
cannot assume that the namespace prefixes in the property names of the
query are the same as the ones in the mapping or in the datastore or
anywhere else. The thing about namespace prefixes is that you can never
make those assumptions.
Another solution for Query would be to provide a list of PropertyNames
rather than strings (which is what I suggested earlier I think?) but I
guess that would break too much existing code ?
And replying to Jody:
> 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.
No. Ideally you really want prefix settings per property name. In fact,
inside one single style file different filters and expression can even
have different prefix data, because in XML you can define them in each
tag; and according to filter specs, the x-paths take their namespace
context from the namespace context of the tags they are in.
Greetings
Niels
On 17/12/10 02:29, 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.
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
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
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
