I had a quick scan as well; I am starting to feel they screwed up this
specification. Sometimes it is the case that the wfs spec plans around
functionality that does not end up making it into filter spec. I wonder if they
just dropped the ball here.
Do any of the temporal functions apply in this situation.
I am going to have to wait until the weekend to write up your proposal; in
general I like the approach although hate Id<ResourceId> pulling double duty.
Specifically it does not allow us to do one of the main use-cases I have for
revisions. Querying history and spatial at the same time (as a poor mans
version of identity management where features are split and merged over time).
While our ability to mix Id and Filter lets us handle this case in GeoTools;
the same functionality is not "strict" WFS.
It also just bugs me; Id was placed in a second pile from Filter for a reason
(since you were doing direct record references something that is not the same
ideas as a judgement call when you evaluate expressions against a record). By
softening RecordId to be a "query object" they are breaking they query model
... it is just bad manners making something so confusing.
--
Jody Garnett
> As far as I can tell, there's no functions defined in the spec to navigate
> the version history of features other than the ResourceId constructs.
> Even more, I see two separate use cases here: 1- querying for version history
> of specific features, and 2- querying for features _at_ a specific (global)
> version.
> 1 is addressed by ResourceId as a query predicate
> 2, though not well elaborated in the WFS 2 spec, I think can be addressed by
> the old and good (?) featureVersion Query attribute. But again the spec is
> too blurry in that regard. So much that Query.featureVersion looks more like
> a leftover than anything. The thing is that if you have versioning support
> you probably have a way to identify the different versions of each individual
> feature, and also a way to identify the different version of each either
> individual datasets or globally (like in svn revision numbers or git
> commits/heads). So yeah, we could use Query.featureVersion to request all the
> features that satisfy the query criteria at a given point in time (version),
> except the spec doesn't provide any mean to query what those versions are (no
> kind of log operation). Though the WFS-V extension do have such an operation.
>
> So in order to answer your question, I think FeatureId could stay confined to
> Feature version information with the properties ID, version, and
> previsousRid, while ResourceId (as a filter predicate) can hold the rid,
> startDate, endDate, and version union type (versionAction|index|timeStamp)
>
> So much that Features don't have to return an Identifier object with a bunch
> of placeholder attributes meant as a query predicate and having nothing to do
> with the identity of the feature.
>
> Gabriel
> >
> > Jody
>
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
