Gabriel I have tried it a number of ways now and am pretty disgusted :-)
I am coming around to something similar to your plan. I do have to keep
ResrouceId as an extension of FeatureId ... because most code we use has
Set<FeatureId> as part of the request; and I think we want to mix up a range of
requests at the same time?
It is not all bad:
- I have made a little progress; mostly reading that the time range and
revision stuff is not both valid at the same time; putting that in the filter
factory makes it a bit easier to take (in terms of complexity)
- I am also getting more comfortable with their crazy crazy situation of asking
for the "previous" version of an existing revision. With that in mind they
don't actually need to have a history ... they can start with the latest and
work backwards.
However I still cannot match the two trouble "use cases" we both mentioned:
1) finding all the features in a bounding box; going back in time. I would like
to be able to mix and match a spatial query with a history time range ...
- even doing it the long way does not work (query a BBox; and then query each
of those FIDs back through time) as you would not be able to discovery a record
that had been deleted in that bbox as it would not show up in your initial BBox
query.
2) you keep mentioning that they lack a concept of "history"
- I think we could ask for a result with no attributes (so just the FeatureID
information); if combined that with a Query that allowed us to request "all
revisions" we would have a good summary of history. It would not have any kind
of change set information but it would allow us to get a good overview of what
data was available; and the ability to go back and fetch just the records we
need.
- We use a similar solution to retrieve a Set<FeatureId> for a spatial query in
uDig (so we can highlight the selected rows correctly in the table view).
With that in mind I am going to write up your proposal pretty; and then propose
an alternate/extension to it where we make use of the Query.getVersion() String
in order to handle the "mixed" case of spatial + revision. Basically
getVersion() can be a subset of RID; with ability to say latest (the default),
all, or a time range. The ability to request a "previous" or "next" does not
make sense in this context.
--
Jody Garnett
On Friday, 21 October 2011 at 10:26 AM, Gabriel Roldan wrote:
> On Thu, Oct 20, 2011 at 9:05 PM, Jody Garnett <jody.garn...@gmail.com
> (mailto:jody.garn...@gmail.com)> wrote:
> > 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.
>
> Can't agree more.
------------------------------------------------------------------------------
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
