Hi Andrea,
Finally got a chance to look your proposal over, i must say this looks
pretty darn cool. I had an idea about how to extend the protocol.
Instead of modifying any of the existing wfs schema files, could we
define all of the needed functionality to support versioning in terms of
new operations? If so, then we could create a new schema which just
imports the wfs schemas proper, and extends any types that it needs to.
For instance, consider the type for a GetFeature reqquest from the wfs
schema:
WFS-basic.xsd:
<xsd:complexType name="GetFeatureType">
<xsd:sequence>
<xsd:element ref="wfs:Query" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="version"
type="xsd:string" use="required" fixed="1.0.0"/>
<xsd:attribute name="service"
type="xsd:string" use="required" fixed="WFS"/>
<xsd:attribute name="handle"
type="xsd:string" use="optional"/>
<xsd:attribute name="outputFormat"
type="xsd:string" use="optional" default="GML2">
</xsd:attribute>
<xsd:attribute name="maxFeatures" type="xsd:positiveInteger"
use="optional">
</xsd:attribute>
</xsd:complexType>
In our schema we create a new type of request, GetFeatureAtRevision (for
lack of a better name) which extends the normal operation type just
adding an additional
WFS-version.xsd:
<xsd:complexType name="GetFeatureAtRevisionType">
<extenstion base="wfs:GetFeatureType">
<xsd:attribute name="revision" type="xsd:string"/>
</extension>
</xsd:complexType>
An idea, it would make extending the schema nice and clean. However it
hinges on being able to create all the needed operations by xml schema
extension and restriction. Not sure if that is possible.
-Justin
Andrea Aime wrote:
> Hi all,
> at Geoserver we are working on developing a versioned WFS-T extension
> which, at first, should provide single branch versioning with history,
> attribution and rollback. Here I have written down the results of my
> research (warning, big document):
>
> http://docs.codehaus.org/display/GEOS/Versioning+WFS
>
> and here is the first implementation proposal (much smaller):
>
> http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal
>
> Geotools already has a datastore, and uDig is using it to provide
> editing. I'd like to hear feeback from anyone interested, especially on
> the WFS protocol extension (and the right way to do it), but on
> everything else as well :-)
>
> As for the implementation of this thing, I'd say at first we're going
> to implement the extension in a postgis datastore "brother", and then
> try to move up the shareable stuff in an abstract class so that other
> JDBC based datastores can enjoy it as well.
> I've left file based datastores out intentionally, since to have decent
> performance I do need a database in the backend anyways.
>
> Possibly in a few days I'll ask for a new module on trunk in order to
> start coding the datastore.
>
> Cheers
> Andrea Aime
>
> -------------------------------------------------------------------------
> 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
>
> !DSPAM:1004,456aa782257356309890654!
>
--
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
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
