[Geoserver-devel] [Geotools-devel] Versioning WFS-T and protocol extensions

Andrea_Aime3 · November 27, 2006, 5:35pm

Justin Deoliveira ha scritto:

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.

Yeah, I was thinking about it myself too... seems like a good plan indeed, and for operations where I cannot cleanly extend the WFS XSD,
I'll just have to copy and hack.
Restriction allows me to better constraint existing element/attributes,
but does not allow me to wipe out existing attributes, right?

I'm also considering this from the point of view of someone that already
implemented WFS-T, and wants to support versioning as well... would the
copy and paste approach from a GetFeature request work for GetDiff?
I don't want to support everything GetFeature has in that call, for example. The same goes for GetLog.
This seems the only clean way, yet it seems more work for implementors... having the protocol dead easy to implement is key, since
we don't have a OpenGIS spec for it (and having "revision" around, we
cannot even try to turn this into a spec, because global revision numbers do expose an implementation detail I guess).

Cheers
Andrea

Justin_Deoliveira · November 27, 2006, 7:45pm

Andrea Aime wrote:

Justin Deoliveira ha scritto:

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.

Yeah, I was thinking about it myself too... seems like a good plan
indeed, and for operations where I cannot cleanly extend the WFS XSD,
I'll just have to copy and hack.
Restriction allows me to better constraint existing element/attributes,
but does not allow me to wipe out existing attributes, right?

Not sure, this is bordering on my knowledge of xml schema but i beleive
you are correct.

I'm also considering this from the point of view of someone that already
implemented WFS-T, and wants to support versioning as well... would the
copy and paste approach from a GetFeature request work for GetDiff?
I don't want to support everything GetFeature has in that call, for
example. The same goes for GetLog.

This seems the only clean way, yet it seems more work for
implementors... having the protocol dead easy to implement is key, since
we don't have a OpenGIS spec for it (and having "revision" around, we
cannot even try to turn this into a spec, because global revision
numbers do expose an implementation detail I guess).

Considering that not many people implement wfs altogether, I dont think
a ton of people will implement wfs-t. I agree that a simple protocol is
a big win, but not if it starts to reek havoc with existing clients.
Having two instances of a single schema (one modified) could quickly
turn into a nightmare.

Cheers
Andrea

-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1004,456b2294224852207481331!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

Chris_Holmes1 · November 27, 2006, 8:16pm

A couple thoughts about extending WFS and making new operations - one approach may be to make it possible for clients to either use the existing operations or to use a new 'shortcut' operation. So for GetLog they can either do a GetFeature on the ChangeSet table and specify everything with filters, or they could use a GetLog call, which simplifies the call, puts the common filter elements as top level attributes (from date/version to date/version, ect.) in the xml request. In our backend we parse them to the same datastructure.

For transactions we can have an alternate operation - versioned-Transaactoin - that requires the revision to be set, has room for a commit message, and has modified transaction response elements. The normal transaction would be allowed, but would automatically version, and would have a place for clients to specify a commit message (our parser would just be fine with either way - since we can just do looser validation). Another possible place for a commit message would be to do it like the rollback operation, as a new 'ElementType' on the Transaction. It'd be a special one that gave a message instead of updating a specific table...

I think GetDiff would need to be it's own operation, there's no real equivalent. And Rollback would be an optional element in a transaction.

best regards,

Chris

Justin Deoliveira wrote:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

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.

Yeah, I was thinking about it myself too... seems like a good plan indeed, and for operations where I cannot cleanly extend the WFS XSD,
I'll just have to copy and hack.
Restriction allows me to better constraint existing element/attributes,
but does not allow me to wipe out existing attributes, right?

Not sure, this is bordering on my knowledge of xml schema but i beleive
you are correct.

I'm also considering this from the point of view of someone that already
implemented WFS-T, and wants to support versioning as well... would the
copy and paste approach from a GetFeature request work for GetDiff?
I don't want to support everything GetFeature has in that call, for example. The same goes for GetLog.

This seems the only clean way, yet it seems more work for implementors... having the protocol dead easy to implement is key, since
we don't have a OpenGIS spec for it (and having "revision" around, we
cannot even try to turn this into a spec, because global revision numbers do expose an implementation detail I guess).

Considering that not many people implement wfs altogether, I dont think
a ton of people will implement wfs-t. I agree that a simple protocol is
a big win, but not if it starts to reek havoc with existing clients.
Having two instances of a single schema (one modified) could quickly
turn into a nightmare.

Cheers
Andrea

-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Jo_Walsh3 · November 27, 2006, 10:44pm

dear Justin, all,
On Mon, Nov 27, 2006 at 11:45:24AM -0800, Justin Deoliveira wrote:

Considering that not many people implement wfs altogether, I dont think
a ton of people will implement wfs-t. I agree that a simple protocol is
a big win, but not if it starts to reek havoc with existing clients.

Have you considered WFS transaction and versioning over WFS Simple?
http://www.ogcnetwork.net/wfssimple

WFS Simple is designed to have a lot more appeal to casual implementors.
OpenStreetmap.org is one project that's been WFS-T curious for awhile
but found the spec overhead combined with the lack of versioning /
history support, unappealing. But they would benefit hugely from
being able to plug into more generic drawing client support than their
current interface allows ( http://wiki.openstreetmap.org/index.php/REST )

While the apogee for a specification is inclusion in geoserver or
mapserver, it would be great if what came out of the geoserver WFS-TV
efforts *was* appealing to and implementable by a ton of people...

cheers,

jo

Chris_Holmes1 · November 27, 2006, 11:37pm

Jo Walsh wrote:

dear Justin, all,
On Mon, Nov 27, 2006 at 11:45:24AM -0800, Justin Deoliveira wrote:

Considering that not many people implement wfs altogether, I dont think
a ton of people will implement wfs-t. I agree that a simple protocol is
a big win, but not if it starts to reek havoc with existing clients.

Have you considered WFS transaction and versioning over WFS Simple?
http://www.ogcnetwork.net/wfssimple

We're definitely following WFS simple stuff there closely. Ok, Justin is, I left the week where it really took off and haven't caught up. But have there been any thoughts thus far to transactions? In the past I've wondered about Atom publishing protocol as an alternative to WFS-T...

I do think/hope our implementation is compatible with things in simple. So you'd be able to use simple to get the latest features, and you could use simple to get the changesets as well (since it's just a table that we can expose as WFS).

I would love it if we could include our ideas on transactions and versioning and the like in WFS-Simple, but unfortunately I do fear that when you get in to transactions, authentication, and versioning you're no longer in 'simple' land (indeed I myself might argue against their place in a simple spec).

Nothing we are doing is incompatible with simple, but most of what we're doing is on transactions and newer stuff (diffs and rollbacks)).

WFS Simple is designed to have a lot more appeal to casual implementors. OpenStreetmap.org is one project that's been WFS-T curious for awhile
but found the spec overhead combined with the lack of versioning /
history support, unappealing. But they would benefit hugely from
being able to plug into more generic drawing client support than their
current interface allows ( http://wiki.openstreetmap.org/index.php/REST )

Yeah, that's definitely one of our goals, to be something that OSM could use to plug in to more generic clients. Indeed I had Andrea check out their API today. When the simple spec settles we're definitely hoping to include it in GeoServer (and I think one of Stefan's students was going to look into an implementation, based at least partially on GeoServer - I need to follow up on the status).

While the apogee for a specification is inclusion in geoserver or mapserver, it would be great if what came out of the geoserver WFS-TV
efforts *was* appealing to and implementable by a ton of people...

We definitely hope so too, and want to encourage people to look over what we're doing to help make it more accessible. I'm definitely open to a REST API that works against the same backend, if that's what's needed for 'easy'. Right now we're just extending WFS-T, since there are clients that implement it already, as opposed to something we just invent, which may not. We'll try to write up exactly what the protocol will look like, if you know WFS you can check out our proposal at: http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal (I just read it and unfortunately it does make assumptions about knowing how WFS works - sorry, as we tighten up and get an implementation we'll definitely make a document of how to do version stuff with no advance knowledge of WFS).

Again though, versioning done right is kind of a complicated thing. We're trying making it as easy as possible. But if you have feedback to help us on making it even easier, we're all ears, for sure. Perhaps WFS Simple first needs to define what a simple transaction is, make a better interface than the current WFS, and then we can build versioning on top of that? Though I have maintained that the Transaction portion of the spec is actually quite nice - maybe 'Simple' could just make it so it doesn't stress about namespace and gml validation and all...

best regards,

Chris

cheers,

jo

-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,456b6acb289729771116852!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Justin_Deoliveira · November 28, 2006, 12:03am

I have been following the wfs simple discussions and like the focus on
usability by mere mortals. However I have to agree with Chris with that
transactions by nature are non-simple. But Andrea's approach to
versioning follows the KISS philosophy so I remain optimistic that the
two will be compatible in some shape or form.

-Justin

Chris Holmes wrote:

Jo Walsh wrote:

dear Justin, all,
On Mon, Nov 27, 2006 at 11:45:24AM -0800, Justin Deoliveira wrote:

Considering that not many people implement wfs altogether, I dont think
a ton of people will implement wfs-t. I agree that a simple protocol is
a big win, but not if it starts to reek havoc with existing clients.

Have you considered WFS transaction and versioning over WFS Simple?
http://www.ogcnetwork.net/wfssimple

We're definitely following WFS simple stuff there closely. Ok, Justin
is, I left the week where it really took off and haven't caught up. But
have there been any thoughts thus far to transactions? In the past I've
wondered about Atom publishing protocol as an alternative to WFS-T...

I do think/hope our implementation is compatible with things in simple.
So you'd be able to use simple to get the latest features, and you
could use simple to get the changesets as well (since it's just a table
that we can expose as WFS).

I would love it if we could include our ideas on transactions and
versioning and the like in WFS-Simple, but unfortunately I do fear that
when you get in to transactions, authentication, and versioning you're
no longer in 'simple' land (indeed I myself might argue against their
place in a simple spec).

Nothing we are doing is incompatible with simple, but most of what we're
doing is on transactions and newer stuff (diffs and rollbacks)).

WFS Simple is designed to have a lot more appeal to casual
implementors. OpenStreetmap.org is one project that's been WFS-T
curious for awhile
but found the spec overhead combined with the lack of versioning /
history support, unappealing. But they would benefit hugely from
being able to plug into more generic drawing client support than their
current interface allows ( http://wiki.openstreetmap.org/index.php/REST )

Yeah, that's definitely one of our goals, to be something that OSM could
use to plug in to more generic clients. Indeed I had Andrea check out
their API today. When the simple spec settles we're definitely hoping
to include it in GeoServer (and I think one of Stefan's students was
going to look into an implementation, based at least partially on
GeoServer - I need to follow up on the status).

While the apogee for a specification is inclusion in geoserver or
mapserver, it would be great if what came out of the geoserver WFS-TV
efforts *was* appealing to and implementable by a ton of people...

We definitely hope so too, and want to encourage people to look over
what we're doing to help make it more accessible. I'm definitely open
to a REST API that works against the same backend, if that's what's
needed for 'easy'. Right now we're just extending WFS-T, since there
are clients that implement it already, as opposed to something we just
invent, which may not. We'll try to write up exactly what the protocol
will look like, if you know WFS you can check out our proposal at:
http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal
(I just read it and unfortunately it does make assumptions about knowing
how WFS works - sorry, as we tighten up and get an implementation we'll
definitely make a document of how to do version stuff with no advance
knowledge of WFS).

Again though, versioning done right is kind of a complicated thing.
We're trying making it as easy as possible. But if you have feedback to
help us on making it even easier, we're all ears, for sure. Perhaps WFS
Simple first needs to define what a simple transaction is, make a better
interface than the current WFS, and then we can build versioning on top
of that? Though I have maintained that the Transaction portion of the
spec is actually quite nice - maybe 'Simple' could just make it so it
doesn't stress about namespace and gml validation and all...

best regards,

Chris

cheers,

jo

-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

-------------------------------------------------------------------------
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

!DSPAM:1004,456b76ed301421804284693!

------------------------------------------------------------------------

_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1004,456b76ed301421804284693!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

Jo_Walsh3 · November 28, 2006, 12:15am

dear Chris, thanks for your prompt and full response,
On Mon, Nov 27, 2006 at 06:37:16PM -0500, Chris Holmes wrote:

I would love it if we could include our ideas on transactions and
versioning and the like in WFS-Simple, but unfortunately I do fear that
when you get in to transactions, authentication, and versioning you're
no longer in 'simple' land (indeed I myself might argue against their
place in a simple spec).

Then 'Simple' is kind of a misnomer. 'Basic' was the original name,
right? I would have thought being able to write a feature to a web
feature service was a fairly basic operation

You don't need much of the rest of WFS, right, to do Transactions?
Like Filter support and POST queries, GML comprehension and emission,
all these non-Simple things. The question is not "why should it be
WFS-T" but "why shouldn't it also be this other, kind of WFS-like thing"

what we're doing to help make it more accessible. I'm definitely open
to a REST API that works against the same backend, if that's what's
needed for 'easy'. Right now we're just extending WFS-T, since there
are clients that implement it already, as opposed to something we just
invent, which may not.

So WFS Simple can be seen just as a more RESTful, geowebbish WFS.
So perhaps i should be having this argument with their discuss list,
and not with you, about Simple implementation of transactions, and use
of the interface for versioning that you are describing, because
transactions without versions are ... like roses without thorns ...
just spammable with worms ... er perhaps i'll try this again in the
morning There will only be clients if there are services, and either
way this is partially going to be something you 'just invent'...

http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal

Nod, i was looking earlier, the extensions are clearly documented but
what would be really helpful would be sample query strings
showing them being used in a request...

We're trying making it as easy as possible. But if you have feedback to
help us on making it even easier, we're all ears, for sure.

No, i'm just kibitzing rather than really offering useful suggestions.

Perhaps WFS
Simple first needs to define what a simple transaction is, make a better
interface than the current WFS, and then we can build versioning on top
of that? Though I have maintained that the Transaction portion of the
spec is actually quite nice - maybe 'Simple' could just make it so it
doesn't stress about namespace and gml validation and all...

This makes a lot of sense... if enough people can consider it in-remit
for Simple...

cheers,

jo

Pat_Cappelaere · November 28, 2006, 2:58am

Jo,

Linda and I have been thinking along the same lines.
Our WFS-Basic (I HATE Simple:) generates GeoRSS Feeds but will also accepts
a GeoRSS feed as input for transaction.
There are some major limitations and assumptions to make but I think that
this is acceptable for Basic functionality.

Pat.

From: Jo Walsh <jo@anonymised.com>
Date: Mon, 27 Nov 2006 16:15:16 -0800
To: Chris Holmes <cholmes@anonymised.com>
Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net>,
<wfsbasic.users@anonymised.com>, Geotools-Devel list
<geotools-devel@lists.sourceforge.net>, <mikel.maron@anonymised.com>
Subject: Re: [WFSBasic.Users] [Geotools-devel] Versioning WFS-T and protocol
extensions

dear Chris, thanks for your prompt and full response,
On Mon, Nov 27, 2006 at 06:37:16PM -0500, Chris Holmes wrote:

I would love it if we could include our ideas on transactions and
versioning and the like in WFS-Simple, but unfortunately I do fear that
when you get in to transactions, authentication, and versioning you're
no longer in 'simple' land (indeed I myself might argue against their
place in a simple spec).

Then 'Simple' is kind of a misnomer. 'Basic' was the original name,
right? I would have thought being able to write a feature to a web
feature service was a fairly basic operation

You don't need much of the rest of WFS, right, to do Transactions?
Like Filter support and POST queries, GML comprehension and emission,
all these non-Simple things. The question is not "why should it be
WFS-T" but "why shouldn't it also be this other, kind of WFS-like thing"

what we're doing to help make it more accessible. I'm definitely open
to a REST API that works against the same backend, if that's what's
needed for 'easy'. Right now we're just extending WFS-T, since there
are clients that implement it already, as opposed to something we just
invent, which may not.

So WFS Simple can be seen just as a more RESTful, geowebbish WFS.
So perhaps i should be having this argument with their discuss list,
and not with you, about Simple implementation of transactions, and use
of the interface for versioning that you are describing, because
transactions without versions are ... like roses without thorns ...
just spammable with worms ... er perhaps i'll try this again in the
morning There will only be clients if there are services, and either
way this is partially going to be something you 'just invent'...

http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementati
on+proposal

Nod, i was looking earlier, the extensions are clearly documented but
what would be really helpful would be sample query strings
showing them being used in a request...

We're trying making it as easy as possible. But if you have feedback to
help us on making it even easier, we're all ears, for sure.

No, i'm just kibitzing rather than really offering useful suggestions.

Perhaps WFS
Simple first needs to define what a simple transaction is, make a better
interface than the current WFS, and then we can build versioning on top
of that? Though I have maintained that the Transaction portion of the
spec is actually quite nice - maybe 'Simple' could just make it so it
doesn't stress about namespace and gml validation and all...

This makes a lot of sense... if enough people can consider it in-remit
for Simple...

cheers,

jo

_______________________________________________
WFSBasic.Users mailing list
WFSBasic.Users@anonymised.com
https://mail.opengeospatial.org/mailman/listinfo/wfsbasic.users

Raj_Singh · November 28, 2006, 5:31am

The WFS Simple page now has a link to a naming poll. Write-ins have to be done in the comments.
Note WFS Basic was abandoned due to it already being defined in the WFS spec as a non-transactional WFS.
---
Raj

On Nov 27, 2006, at 9:58 PM, Pat Cappelaere wrote:

Our WFS-Basic (I HATE Simple:) generates GeoRSS Feeds but will also accepts
a GeoRSS feed as input for transaction.

Raj_Singh · November 28, 2006, 5:35am

I kind of agree with Chris. To do transactions right moves out of Simple land. Once you want to update or edit a data set you need to know all kinds of things about the structure of that data. Not to mention the other issues. Maybe openstreetmap people could offer some advice?
---
Raj

On Nov 27, 2006, at 7:15 PM, Jo Walsh wrote:

On Mon, Nov 27, 2006 at 06:37:16PM -0500, Chris Holmes wrote:

I would love it if we could include our ideas on transactions and
versioning and the like in WFS-Simple, but unfortunately I do fear that
when you get in to transactions, authentication, and versioning you're
no longer in 'simple' land (indeed I myself might argue against their
place in a simple spec).

Then 'Simple' is kind of a misnomer. 'Basic' was the original name,
right? I would have thought being able to write a feature to a web
feature service was a fairly basic operation

You don't need much of the rest of WFS, right, to do Transactions?
Like Filter support and POST queries, GML comprehension and emission,
all these non-Simple things. The question is not "why should it be
WFS-T" but "why shouldn't it also be this other, kind of WFS-like thing"

Andrea_Aime3 · November 28, 2006, 8:01am

Jo Walsh ha scritto:

dear Justin, all,
On Mon, Nov 27, 2006 at 11:45:24AM -0800, Justin Deoliveira wrote:

Considering that not many people implement wfs altogether, I dont think
a ton of people will implement wfs-t. I agree that a simple protocol is
a big win, but not if it starts to reek havoc with existing clients.

Have you considered WFS transaction and versioning over WFS Simple?
http://www.ogcnetwork.net/wfssimple

At the moment I did not, in fact, but being a different protocol set I don't see why we could not set versioned stuff on top of it.
Yet, they do seem to be orthogonal... simple focuses on data retrivial,
while versioning focuses most on data update and its management.

My take here is that Geoserver could (and should, if simple becomes a spec) provide data with simple protocol, but transactions are not simple...

WFS Simple is designed to have a lot more appeal to casual implementors. OpenStreetmap.org is one project that's been WFS-T curious for awhile
but found the spec overhead combined with the lack of versioning /
history support, unappealing. But they would benefit hugely from
being able to plug into more generic drawing client support than their
current interface allows ( http://wiki.openstreetmap.org/index.php/REST )

This seems an argument in favour of the more heaviweight WFS-T, since
you already have various client that are able to work against it.
Versioning and attribution should add what you're missing from the
initial spec.

While the apogee for a specification is inclusion in geoserver or mapserver, it would be great if what came out of the geoserver WFS-TV
efforts *was* appealing to and implementable by a ton of people...

I hear you. At the same time, I do feel like if you give away the WFS-T
complexities you're left with... nothing?
Do consider the WFS-simple in its current state. Even to simply read information, I have to go down and code (yes, code) support for the
format they decided to give me feature in.
Compare this with WFS: I do have a client, I point it to a server,
and voilà, as a user I can manage what was returned without hassle
because I know that I can ask things in GML and I can interpret it
because it's self describing. No extra programming needed.
It gives me the impression that WFS complexities are just moved to
another level, that is, instead of having one very complex implementation, you have many simple, potentially one per server
and format the provided decided to implement.

Cheers
Andrea
of the client, you

Andrea_Aime3 · November 28, 2006, 8:41am

Jo Walsh ha scritto:

dear Chris, thanks for your prompt and full response,

...

You don't need much of the rest of WFS, right, to do Transactions? Like Filter support and POST queries, GML comprehension and emission,
all these non-Simple things.

Hmm... I kind of disagree here, but it may be just lack of real world experience. Let me tackle this point by point:
* no filter support... ok, this may be, but remember you're giving
   up the ability to do mass updates this way.
   Like in update mytable set myatt = value where <here is the filter>
* no POST query... here you give up the ability to modify all but
   a handful of features at a time (GET is no good for big sized
   parameters afaik).
* GML comprehension and emission. Hem, you have to encode features that
   need to be inserted in a way that's agreed upon between the client
   and the server. How do you do that if you don't mandate a standard
   format? And I don't mean it has to be GML (see my other mail about
   the lack of standard format in WFS-simple).

http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal

Nod, i was looking earlier, the extensions are clearly documented but
what would be really helpful would be sample query strings
showing them being used in a request...

Well, I could take some from the WFS spec and modify them to show versioning usage. Yet, a WFS extension follows its parent destiny: you
cannot just play with it "by example", you really have to code it with
an understanding of the WFS schemas. Examples are nice thought, I will
add some.

Cheers
Andrea

Chris_Holmes1 · November 28, 2006, 4:23pm

Andrea Aime wrote:

Jo Walsh ha scritto:

dear Chris, thanks for your prompt and full response,

...

You don't need much of the rest of WFS, right, to do Transactions? Like Filter support and POST queries, GML comprehension and emission,
all these non-Simple things.

Hmm... I kind of disagree here, but it may be just lack of real world experience. Let me tackle this point by point:
* no filter support... ok, this may be, but remember you're giving
up the ability to do mass updates this way.

> Like in update mytable set myatt = value where <here is the filter>

Actually you could do a mass update with their optional regular expression filtering.

But I think for most collaborative web stuff you don't so much need the ability to do mass updates (and if you do we'll still provide the full WFS-T way). You basically want to insert features and update them.

* no POST query... here you give up the ability to modify all but
a handful of features at a time (GET is no good for big sized
parameters afaik).

I think you'd have to allow POST, but that's compatible with a general REST philosophy, and expressed in both OSM api and Atom Publishing Protocol.

And actually I think the way they handle updates is to just basically do an insert on an existing feature, and it will overwrite it (I could be wrong on this, Mikel? others?)

Also, why is there not featureid filtering in WFS Simple? I think this is essential for a simple transaction protocol - so you can specify which feature you're actually updating.

* GML comprehension and emission. Hem, you have to encode features that
   need to be inserted in a way that's agreed upon between the client
   and the server. How do you do that if you don't mandate a standard
   format? And I don't mean it has to be GML (see my other mail about
   the lack of standard format in WFS-simple).

Yes, I agree with this. You need some sort of standard way to encode features. I'm confused about WFS simple right now, since the example seems to be atom, but what I'm curious about is data that's not in a natural atom format.

It'd be useful if there's an example of going from like csv or excel spreadsheet to WFS Simple. An ideal would be a basic xml format that's self describing - no nesting, one geometry ect. (like Peter's original Simple Features for GML proposal, using Georss for geometries). But you need to define what that is, and how one has to encode something to send it to a WFS-Simple-Transactional.

http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal

Nod, i was looking earlier, the extensions are clearly documented but
what would be really helpful would be sample query strings
showing them being used in a request...

Well, I could take some from the WFS spec and modify them to show versioning usage. Yet, a WFS extension follows its parent destiny: you
cannot just play with it "by example", you really have to code it with
an understanding of the WFS schemas. Examples are nice thought, I will
add some.

Cool.

Chris

Cheers
Andrea

-------------------------------------------------------------------------
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,456bf6db35671429667743!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Chris_Holmes1 · November 28, 2006, 4:35pm

Jo Walsh wrote:

dear Chris, thanks for your prompt and full response,
On Mon, Nov 27, 2006 at 06:37:16PM -0500, Chris Holmes wrote:

I would love it if we could include our ideas on transactions and versioning and the like in WFS-Simple, but unfortunately I do fear that when you get in to transactions, authentication, and versioning you're no longer in 'simple' land (indeed I myself might argue against their place in a simple spec).

Then 'Simple' is kind of a misnomer. 'Basic' was the original name,
right? I would have thought being able to write a feature to a web
feature service was a fairly basic operation

Yeah, I agree, that'd be nice.

You don't need much of the rest of WFS, right, to do Transactions? Like Filter support and POST queries, GML comprehension and emission,
all these non-Simple things. The question is not "why should it be
WFS-T" but "why shouldn't it also be this other, kind of WFS-like thing"

As I said before, I think you need POST for Transactions, but I think this is in line with how others are doing it. I think you could successfully drop much of the rest, have it be about updating and inserting single features. And you could theoretically even combine insert and update to be the same thing (and you'd just version it).

what we're doing to help make it more accessible. I'm definitely open to a REST API that works against the same backend, if that's what's needed for 'easy'. Right now we're just extending WFS-T, since there are clients that implement it already, as opposed to something we just invent, which may not.

So WFS Simple can be seen just as a more RESTful, geowebbish WFS.
So perhaps i should be having this argument with their discuss list,
and not with you, about Simple implementation of transactions, and use
of the interface for versioning that you are describing, because
transactions without versions are ... like roses without thorns ...
just spammable with worms ... er perhaps i'll try this again in the
morning There will only be clients if there are services, and either way this is partially going to be something you 'just invent'...

Yeah, the big thing you really need is a default encoding. I think it's ok if you don't have it for WFS reading, but if you're having clients update the server you really should pick one. Hopefully that's self describing, flat and simple. GML Level -1

http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal

Nod, i was looking earlier, the extensions are clearly documented but
what would be really helpful would be sample query strings
showing them being used in a request...

Yeah, I realized that when I posted it, it's aimed at WFS people. We'll work on it.

Andrea, we should probably put implementation and protocol stuff on separate pages...

We're trying making it as easy as possible. But if you have feedback to help us on making it even easier, we're all ears, for sure.

No, i'm just kibitzing rather than really offering useful suggestions.

Perhaps WFS Simple first needs to define what a simple transaction is, make a better interface than the current WFS, and then we can build versioning on top of that? Though I have maintained that the Transaction portion of the spec is actually quite nice - maybe 'Simple' could just make it so it doesn't stress about namespace and gml validation and all...

This makes a lot of sense... if enough people can consider it in-remit
for Simple...

Yeah, let me know if you guys want to go for it, I'm happy to help out with developing that protocol. Heck, if we do it well and fast we might implement that first (I do believe for GeoServer we should do both simple and advanced ways for transactions - half because we already have clients for the more advanced stuff).

Thanks for sounding in Jo. It may make sense to wait for the read only simple stuff to settle down first, and to have us prototype with our WFS-T way, but it's good to at least think about it a bit now.

best regards,

Chris

cheers,

jo

-------------------------------------------------------------------------
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,456b8c6b314401219810056!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org