The handle attribute allows a client application to assign a
client-generated request identifier to a WFS request. The handle is
included to
facilitate error reporting. A WFS may report the handle in an
exception report to identify the offending request or action. If the
handle is not present, then the WFS may employ other means to
localize the error (e.g. line numbers).
I have only ever seen it used by external applications to note what they
were doing (often in human readable or supplied terms).
I like the idea of using handle here - gives us a chance pick up what
non version aware clients thought they were doing:
#1 Use Handle (even if we are bending)
I kind of like using the handle. It's never used by people, if you put
a commit message in there then it can still be used for error reporting,
it's ostensible purpose. Just like the versioning stuff that's in the
WFS spec it's a piece that's not thought out and used, so we can exploit it.
The big problem I see is the semantics are wrong. It won't be intuitive
to the writer of a new client that they the 'handle' attribute is the
place to put their 'comment' or 'message' for their commit.
Another somewhat open question I have is how wise it is to try to
bootstrap everything on top of WFS-T. I do think it makes sense for the
first crack, so we get a bit of extra versioning on WFS-T commits from
clients that may not know our versioning protocol, and make it super
easy for them to add it.
So the question for you Jody, or maybe more accurately for DavidZ if he
was still around, is how easily could you add versioning support on top
of the existing gt2 WFS-T stuff? Not _necessarily_ what matches the
WFS-T spec as close as possible, but what would make it easy for you as
an implementor? This also informs like what and how we respond to a
GetDiff call.
In the future it might also make sense to just throw out the whole WFS-T
way of doing things, and adopt something more RESTful, and perhaps use
like GeoJSON: http://icon.stoa.org/trac/pleiades/wiki/GeoJSON maybe
expand to use WKT?
Forcing handle to be used as a commit message would be wrong in my
opinion...
#2 Use a <!-- comment -->, and consider myself requesting you store the
"handle" as a seperate addition to your table
I don't understand this. You're talking in the XML? If it's in the XML
I don't think there's a way for DOM or SAX to get at the comments? So
we wouldn't be able to read them in GeoServer...
Chris
-------------------------------------------------------------------------
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:1003,456dd188314807785049143!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
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
