Rob Atkinson wrote: > On the Xpath front... > fully implementing xpath seems an unecessary burden, but partial > implementation has its issues. That is why we are trying for *no* implemenation of xpath :-)
Even the use of "Name" for look up is just a helper method, ... the same as going through the attributes and find the one with the name you want). Note we were using a strongly typed Name make this "search" unambigous (as upposed to using a plain String). The fact that we are taking about this for more than a couple emails means we should probably remove it as a possible source of confusion. > The OGC allows xpath in the Filter specification, stating > > "In order to handle property references in a consistent manner, a > filter expression processor must use the subset of XPath [10] > expressions defined in this document for referencing simple properties > and the properties and sub-properties of objects with complex or > aggregate non-geometric properties or properties encoded as XML > attributes." > > It seems reasonable IMHO to implement this subset. Agreed; and we do - that is the subset we use for the filter implementation. The job of the feature model here is to represent the data the application has; adding even the subset indicated above goes way beyond what we can expect of implementors. Remember the goal here is interoptibility; every method we put in the here has a cost. Xpath just has too high a cost; especially for something that can be done another way. Perhaps next year we will have more experience and view the cost of XPath as doable - but for now the only thing we have is a prior history of failure here. Cheers, Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
