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
