Hi Andrea, Going to concentrate my feedback the following (since that is probably what you need to start coding):
> http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal > Sorry for the delay in getting back to you, Jesse has also looked over the following feeback for me. Jody -------- You are clear on your scope (and yes everyone's hopes ask for more, but I respect your decision to start small). Datastore Desgin: Data table: - I was not going to assume the revisionCreated - revisionExpired columns; instead used to a single "revision" column that only becomes non 0 when it is replaced (so revision==0 always represents the "live" data). Having two columns is not bad, does having both help you ask for data in a specific range? Or could we get by with just a single column. Authentication: - correct lets deal with this out of band. WFS protocol extensions You base line goals are all clear. > plain GetFeature call must return the latest revision; Check > Transaction, in absence of branches, works just like usual from the > user point of view (but of course creates new versioned records > instead of altering existing ones); Check > Lock, in absence of branches, works the same as usual, too, so it's > intended to work against the last revision (probably some changes are > needed to handle actual record changes during the lock duration). Check. GetFeature - so out of the box it returns the latest I am a bit concerned that making the revision columns available messes up the origional schema (this simply will not work in the case where the schema is provided by a third party authority for example). Although this is not your use case (I recognize that) I am going to work through how it can be done: Use getFeature with a vendor specific parameter describing the revision range. The result of which is a GML document where the revision is either: - part of the feature identifier <Feature fid="people.fred.432456">..</Feature><Feature fid="people.wilma.432455">...</Feature> - separate attribute on each feature (ie not element) <Feature fid="people.fred" revision="432456">..</Feature><Feature fid="people.wilma" revision="432455">...</Feature> (preferred approach?) By making the concept of revision available as an attribute the normal describeFeatureType method can provide the correct description as part of the schema - ie the exact revision range that will work. GetLog - making it available as a normal feature is fine, collections support can be done if you need it. Transation: - throwing errors out of Transaction is cool; consider any conflict to be the same as a locking conflict (ie the modification has been made by another so that feature is "locked") - leave revision columns out of the describe feature type so that you do not have to worry about user's supplying the details... The Transaction "handle" is where your changelog message comes from. No additional extra attribute is needed from the Transaction element. When returning revision number no extension is required if you consider revision information part of the identifier - to with make use of: - <FeatureId>people.fred.432456</FeatureId> - <FeatureId revision="432456">people.fred</FeatureId> (preferred) Remember that matching Identifier is fnally under control on geotools trunk; so you have the ability to make "people.fred" and "people.fred.432456" match as needed. GetDiff - GetFeature option Good summary; the allowing each attribute to be optional is tough. One way to consider this is the WFS1.1 idea of different formats; define a "diff" format that produces an xml document such as you describe; you can always include the modified XSD information incline as part of the document (since in this case the amount of data is small, and the modifications to the original XSD are known). GetDiff - GetTransaction Request option It would be *nice* if the result was *not* a GetFeatures extensions but instead the exact Transaction request documented required to make the change; no messing around or inventing new xml schema is requried here. This is consistent with Galdos cascading WFS-T approach and would be a *great* benefit for keeping servers in sync. (Please consider this idea). Rollback - don't do it, use GetDiff No comment on the SQL - as I am out of time. Except that after we prototype it would be smart to roll this stuff into the database side; although not as Paul suggests straight into PostGIS (smarter to do it as part of DataStore initialization, so the java code "owns" the SQL). Cheers, Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
