Thanks for the examples Niels. You are correct that the existing property classes reflect the filter spec pretty much exactly (so we can work with external wfs servers for example). As it uses xpath; and xpath is a string representation it does not provide more information than a string (well you can actually get tricky and refer to attributes and all manner of stuff and JXPath implementation should handle it).
So while we could add a property( List<Name> path ) entry to our filter factory to work around this problem formally; I would like to ask how you would handle your example when submitting a wfs GetFeature request. Is this really outside of what xpath can do? The filter is supposed to be constructed (by the person writing it) for a specific context - so being context dependent is not terrible. Is there anyway you can remove the context? You could put everything into a long full qualified form (ie untangle the prefix when you know what is going on); and then be able to simplify again when producing a filter for the new context? As for Query; I thought we had extended that to be a List<Name>; if not now would be a good time. So there are two ideas on the table: - Do you need FilterFactory.property( List<Name> )? It could possibly be a terrible idea if it breaks xpath compatibility - Do you need a Query.attributes(): List<Name> (well actually you have the same issue here right; you may want each entry to be an XPath - so something like Query.attributes(): List<Path> ) Other than that you may need to make a Path data structure to describe what is going on; I would prefer to avoid that; and look at how JXPath handles things and see if it would work for you. Jody On 10/12/2010, at 2:49 PM, Niels wrote: > Jody, > > The issue lies in the mappings between the prefixes and the actual namespace > URN's. > For example gsml maps to urn:cgi:xmlns:CGI:GeoSciML:2.0 > > This really is very context dependent. It is perfectly possible that you want > to compare two x-paths with different namespace mappings, for example because > one comes from a request or a style file and the other one from the > datastore. > One could be mapping the prefix 'foo' to urn:cgi:xmlns:CGI:GeoSciML:2.0 and > you have to be able to detect that the foo from one path is the gsml from the > other. > > Currently we are writing the prefix:namespace mappings in the expression's > hints where they are picked up by a property accessor that can handle it. > Because of the dependance it is a very good idea to store it in the > expression object. The issue I am encountering though, is that the existing > API doesn't support property names that contain more information than a > string as a name. > > For example, I succeeded in parsing the style file with namespace support, > but then later noticed that the style's filters where being cloned somewhere > by a visitor using a new filter factory and that the hints were being thrown > away. The FilterFactory interface only accepts a string to create a fresh new > PropertyName, and nothing more, and that can't be changed as it is part of > GeoAPI. The only solution I see is to make some interface extensions in > geotools to support xpath property names and some if (instanceof) tricks to > deal with them. > > Another issue is the 'propertynames' field in a Query object. This is > currently implemented as an array of strings. With app-schema, x-paths with > namespaces should be supported for this field, and as I explained before, > there is no guarantee that the prefix mappings in the query are the same as > the ones in the datastore. Currently namespaces just need to be ignored > there, which is a 100% guarantee for buggy behaviour in certain cases. > > With Regards > Niels > > On 10/12/10 11:27, Jody Garnett wrote: >> >> Hi Niels; I did gradually sort out (well in conversation with aaime) that it >> was as part of a longer xpath expression you were having trouble. >> >> How does the xpath specification handle this? It was our intension to just >> use xpath and let the jxpath implementation sort out the details? At the >> very least it should be able to parse it into a data structure you can >> negotiate in greater details if needed. >> >> Jody >> >> On 06/12/2010, at 1:58 PM, Niels wrote: >> >>> Hi, >>> >>> Sorry for my late reply as I was on leave. >>> >>> I think you are misunderstanding. I am trying to create expressions based >>> on nested x-paths, that means it contains different steps of which each >>> have their own namespace prefix. A 'Name' object can only contain one of >>> such steps. >>> >>> Regards >>> Niels >>> >>> On 26/11/10 22:33, Jody Garnett wrote: >>>> >>>> The Name class is supposed to handle what you are doing; if not please let >>>> me know and we can fix it :-) >>>> >>>> We introduced the Name interface when String was no longer cutting it; but >>>> yeah give it a once over and let me know if does the job for you. >>>> >>>> The other interesting aspect of your email was the idea of feeding a hint >>>> into the factory. >>>> >>>> In general we don't want the factory to be stateful (instead we wrap a >>>> builder around it to be helpful and insert magic as needed). >>>> >>>> Constructing it with a hint would actually work - at least the state would >>>> not change at runtime which would make it safe to use. >>>> >>>> Before you take that approach please consider the use of Name; it is >>>> already there in order to encourage the gradual adoption of namespace. >>>> >>>> Jody >>>> >>>> On 26/11/2010, at 5:46 PM, Niels wrote: >>>> >>>>> On 26/11/10 15:21, Jody Garnett wrote: >>>>>> >>>>>>> We should be able to create a Property filter with a complete Name >>>>>>> (rather than a String) and thus store the namespace information). Are >>>>>>> you sure this is not already possible? >>>>>>> >>>>>> Checking the java docs for filter factory: >>>>>> PropertyName property(Name name) >>>>>> PropertyName property(String name) >>>>>> >>>>>> So you should be able to create a filter that supports namespace right >>>>>> now. >>>>> No, what I mean is to create an expression based on an x-path, not on a >>>>> name. >>>>> An x-path contains prefixes rather than namespace URI's and is nested. >>>>> In a filter on complex features one should be able to fill in a nested >>>>> x-path as filtering attribute rather than a property name. >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >>> -- >>> 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 >> > > > -- > 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
------------------------------------------------------------------------------
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
