On Thu, Oct 20, 2011 at 11:02 AM, Jody Garnett <jody.garn...@gmail.com>wrote:
> Q: I was not able to find any evidence in the specification for a
> getPreviousVersionFID() method; did I just miss it in the WFS 2 and Filter
> 2
> specification or is this something that came out of the GeoGit work?
>
> no it doesn't come out of anything GeoGit specific.
> It matches FES 2.0 previousRid element of ResourceId
> <http://schemas.opengis.net/filter/2.0/filter.xsd>
> And the spec says about it: "The previousRid attribute may be used, in
> implementations that support versioning, to report the previous
> identifier of a resource" (section 7.11.2).
>
> Thanks for that I was wondering.
>
>
> I like the second option better than the first one, but don't like neither
> enough.
>
> :-)
>
> That is the spirit.
>
> Rationale is I think it's weird to mix up query predicate and
> reporting properties on the same interface, so at this point I would
> like for our object/query model not to follow the schema definition of
> ResourceId to the letter.
>
> To be clear I am never going to mix our data model, query and metadata
> model.
>
> However before we get too distracted - I think you may of missed the
> following part of the wfs2 specification. Details after the break ..
>
> I think we can have ResourceId as a filter predicate, and a
> minimal extension of FeatureId to support reporting of versioning
> information. Something on the lines of:
>
> I will add your idea to the wiki page and get back to you when I have had
> some more thought.
>
> Does that make sense?
>
> I understand (and applaud) the separationl but I expect we may be working
> too hard.
>
> Here is the part of wfs2 that is interesting on this topic:
> *7.2.3 Version identification*
> *If the server supports versioning of features, then the server shall
> maintain version information about each feature instance. This International
> Standard makes no assumptions about how that version information is
> maintained. Functions defined in the Filter Encoding Standard (see ISO
> 19143, 7.11.2) allow version navigation based on the resource identifier.
> *
>
> I take that to mean:
> - ResourceId is going to identify a specific Record in the history of a
> Feature
> - They have a separation of concerns with the Functions defined by the
> Filter Encoding specification offering the "Query" side of things
>
> So it is my hope that we we need to make use of ResourceId as a query
> object. We can keep FeatureId and it will always only describe one record;
> we will make use of functions in order to make a time based query.
>
> So the next question is what functions are they referring to in the Filter
> specification; and do we think those functions are specific to meet your
> GeoGit use cases?
>
> Aside: ResourceId is obviously the only show in town for identifying a
> feature; so I have no problem leaving it as FeatureId
>
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@Ciosco 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
