Chris Holmes ha scritto:
Looks really great.
A few small feedbacks:
I like <FeatureCollection .... xsi:type="VersionedFeatureCollection" featureVersion="11502"> better than <VersionedFeatureCollection ...>. I feel like clients might barf if they get back a versionedFeatureCollection.
Unfortunately that does not work very well with multiple versioning
data stores and non versioned feature types. The second proposal handles
that.
To keep things compatible with older clients, we can use a VersionedFeatureCollection only if the client showed knowledge of the
versioning api, that is, only if GetFeature did use featureVersion.
In GetDiffType you have a mismatch between documentation and xml for output format. Docs say:
The default value of 'application;xml; subtype=wfsv-transaction/1.1.0'
Schema says:
<xsd:attribute name="outputFormat" type="xsd:string" use="optional" default="text/xml; subtype=gml/3.1.1">
Ops. Will fix that.
Regarding diff, I'm having second thoughts on using Transaction as
the default output. While the structure is good, both delete and update have a full Filter element inside.
A server could theoretically log all wfs-v transaction requests and build an optimized and compact diff that leverages a lot filter spec, but I do believe this would raise the bar, both on the server side (a bit), and on the client side (too much to hope for a widespread adoption).
On RollbackType you might want to explain in the documentation why you're requiring a Filter. I imagine it's because you don't want people accidentally leaving one off and rolling back everything. But you should maybe explicitly state that, and tell them to do a 1=1 filter or some such if they really want to rollback everything.
Right. Explanations added, read that, because it's not really what you
were thinking about 
That is, it wasn't meant for safety against big bad rollbacks, we do "unfiltered" rollbacks on subversion all the time, right?
There is still one important thing left out, that is, user identification: you may want to roll back stuff that a specific user did. Unfortunately user id is not in the feature type.
Now that I think about it, filtering against user is something you
may want to do in GetDiff, GetLog, and GetFeature too.
I can think of a couple of ways to handle that:
* have it in the filter anyways, as a phantom attribute, but say
we do handle "user = xxx" only if it's a top level element of a
"and" filter.
* extend GetFeature, GetLog, GetDiff and Transaction to have a
userFilter element, with a list of user names in it. This does
not allow, in general, for fancy filters that do restrict on users
only when other conditions are met as well, but it's a lot simpler
to implement. I do believe it's a big uglier, too.
* leave it all to the client, helping it a bit.
Since user name is part of the GetLog output, and that the ChangeSets
feature type is published anyways, have the client first
filter against the user to find out revisions where the user did
modify something, and then do a GetFeature against a range going from
the lower to the higher.
In order to make this work, we would need to revisit how version
filtering works, and maybe go back to having a single featureVersion
attribute that can be understood as:
* empty, implying a single value, LAST
* single value (value of features at that version)
* range [v1,v2] -> all versions of features modified between
v1 and v2 (bounds included?)
* list {v1,v2,...,vn} -> all versions of features that has been
modified at those specific versions
* ALL (since the WFS spec reports it)
The client would then issue a GetFeature asking for a list of
revisions where the user has changes something, and then use that
very list in a GetFeature, GetLog or GetDiff call.
Hum, the idea of using featureVersion being handled as a range or as a list is indeed interesting, it would reduce the amount of changes we
need in the XML structure even further (no DifferenceQuery element would be needed). I'm inclined to go down this road, unless I receive negative
feedback. The only thing I don't like very much, is that featureVersion
this way becomes complex enough to justify a sub-element for it,
instead of an attribute.
Especially since the single version can already be understood as
number, timestamp, branch:number, branch:timestamp (ugh..)
But yeah, other than those everything looks really good. After you've implemented we should make a more friendly 'API' page, that is mostly examples instead of XSD snippets, as few people actually understand those. But this is a great explanation for OGC types.
Will sure do. And provide a Geoserver with sample versioning requests too.
Cheers
Andrea