Chris Holmes ha scritto:
Hey Andrea, Tim and I were chatting last night about a few improvements for wfs-v.
The first major goal is to make it easier to get the latest history without having to do two requests / tracking what revision we're at. What we came up with was to follow svn and allow users to do a toFeatureVersion or fromFeatureVersion of 'HEAD', which will be the current feature. So you could say something like:
<wfsv:GetLog
<wfsv:DifferenceQuery toFeatureVersion="HEAD" maxFeatures="20"/>
</wfsv:GetLog>We need a few more things to make this work though. maxFeatures currently seems to have no effect, so we need to make it so it does. And things also seem to blow up if there's not also a fromFeatureVersion. I'm thinking we should have defaults for fromFeatureVersion of '1' and 'toFeatureVersion' of HEAD?
You can already avoid inserting toFeatureVersion and it will be interpreted as the last revision in fact. And there is already
code that interprets "CURRENT" and the emtpy string as the latest one.
So I can:
1) make it so that fromFeatureVersion defaults to "1"
2) eventually rename CURRENT to HEAD (if you prefer that one).
Does this make sense to you? How hard would implementation be?
Easy and relatively quick (the cleanest way is to update the schema to make sure fromFeatureVersion defaults to "1" and regenerate the bindings).
The other improvement we were thinking of is that if you do a GetLog query and leave off any typename it should behave like DescribeFeatureType - that is it should grab information for all the featureTypes. In this case get the whole history. This way a client doesn't have to know beforehand what featureTypes there are (though I agree it'd be very rare that they didn't).
Well, the code is made up so that it needs a feature type, and the log
operation is feature type specific because there is the Query element.
Anyways, to handle this I could add a getLog operation in the DataStore
(now it's coded against FeatureStore).
Another concern is that DifferenceQuery featureType is required. If I
make it optional, then the filter would stop making sense. Also, GetDiff
uses DifferenceQuery too. Do you want a generalized diff as well?
Doing a general GetLog is more work, but still manageable (less than a day I guess).
Finally, do we have a pluggable mechanism for new output formats for GetLog? I want to offer XML and JSON output for the log. Tim is actually using a GetFeature request on the changesets featureType because he likes the XML better. And because in the example requests it's a bit confusing the difference between that and a GetLog request. You agree that the history should always be gotten with a GetLog request, instead of doing a WFS GetFeature call? If so we may consider removing or at least moving to the end the WFSV_04_GetFeatureLog requests, so as to not confuse potential implementors.
Yes, I can do that, GetLog in fact already can output GML3, I can add
GML2 and JSON to the mix as well. I just thought the HTML version would
have been easier for the user to look at in the demos.
As for removing WFSV_04_GetFeatureLog, no problem. I wanted to point out
the possibility of going straigt to the changelog table because you
could use it for things we did not think about. Maybe I can remove
that call and issue a GetMap using it, so that the bounds of the
changes change be overlayed with the current map.
Cheers
Andrea