Skip to end of metadata
Go to start of metadata


Styling and Query need a hint to understand xpath namespaces


Jody Garnett



xpath across deep waters

This page represents the current plan; for discussion please check the tracker link above.



The goal is to enable the following code example that uses xpath namespaces:

Additionally, the interface for PropertyName should be should allow getting namespace information , especially for duplication purposes:

Query should be extended to support the PropertyName type rather than just strings, for greater control of properties returned:

For backward compatibility, the existing getter and setter with String[] rather than PropertyName[] with remain supported.

Assumption: In the above that description will be returned; with only one the "label" value filled in.

This is a straight up API change to roll in the work of FilterFactoryImplNamespaceAware for broader use. This issue also effects the use of Query (another place where NamespaceSupport is required in order to understand propertyName expressions).

The above code allows a NamespaceSupport instances provided along side an PropertyName. This can be used to sort out any prefix information mentioned by the PropertyName XPath expression.


  • The correct solution (fixing FilterFactory2) is complicated as it is a GeoAPI interface
  • Hints are not used in the usual CommonFactoryFinder lookup sense; NAMESPACE_CONTEXT could be used as part of the factory Hints allowing for some reuse (and probably a memory leak)
  • Factory is stateful; which may cause problems as it is common practice to both:
    • ignore a provide factory finder and use common factory finder (common in newer code)
    • capture a filter factory for use later when you need it (common in older code)
  • NamespaceSupport is a class; and may appear out of the way for someone issuing a Query to fill in a sax support structure. The alternative interface, NamespaceContext is hard to locate a good non deprecated implementation (gabriel was still looking at the time of writing)


Work has completed; the jira was marked as resolved.

Voting is open:


This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success


no progress






lack mandate/funds/time


volunteer needed

  1. (tick) NC: Update Query based on BEFORE/AFTER
  2. (tick) Proposal Refactor OpenGIS to pull geo-api pending into gt-opengis module
  3. (tick) Move CommonFactoryFinder to gt-api
  4. (tick) NC: Update FilterFactory2 based on BEFORE / AFTER
  5. (tick) NC: Migrate app-schema to use FilterFactory2 method
  6. (tick) NC: review user documentation for any needed changes

API Changes








Pending the acceptance of Refactor OpenGIS.



  • No labels