[DAS] [Fwd: Re: Writeback implementation]
Gregg Helt
gregghelt at gmail.com
Fri Oct 31 17:34:44 UTC 2008
On Fri, Oct 31, 2008 at 7:22 AM, Andy Jenkinson <andy.jenkinson at gmail.com>wrote:
> I can't find a description of the response to a writeback command in Asia's
> thesis. Does it contain features (as in DAS2) or just a confirmation?
Take a look at the writeback spec (
http://biodas.org/documents/das2/das2_writeback.html ), it's much shorter
than the retrieval spec, just a few pages.
The general idea is that a server may not be able to do all the
creations/edits/deletes a client is requesting in exactly the same form the
client has specified, and furthermore that changes a client requests in one
feature can possibly trigger changes in other features. Therefore the
semantics of the client request are "here's what I want to do" and the
writeback server responds with "here's what I actually did". In the DAS2
writeback spec these are communicated mostly by passing back and forth
feature XML, except for deletion getting it's own special bit of XML.
> Just to reinforce what you are saying about Dasty being a 1.53 client, it's
> important that we're clear about the goals of your project: to add writeback
> to DAS (as it is currently) via Dasty. This is independent of DAS/2. If
> Gregg's code can help you it of course makes sense to use it, but you do not
> have to support all of DAS/2's data model.
>
Agreed. I don't mean to divert Gustavo's project from it's goals. I just
wanted to point out that if the intent is to implement the current DAS/2
writeback spec that implies use of parts of the DAS/2 retrieval spec as
well. And if the intent is also to use MyDas then that implies some
DAS1<-->DAS2 transformations will be needed, in which case the Trellis/Ivy
code base could be useful.
Reading the DAS2 writeback spec for the first time in a while I see that
there are a few bits that need to be expanded. But I also see parts that
could be simplified. Possibly simplified to the extent that it could become
a more generic writeback interface that requires of the XML "payload" only
that the entities to be created/edited/deleted have ids in their XML
representation, and that writeback requests/responses can inject "old_id"
and "delete" attributes/elements into those XML representations. If we go
in that direction then I think DAS2 writeback could evolve into a more
general DAS writeback that could be used for DAS2, DAS1.53, and probably
many of the DAS extensions.
I'll try to write up a more specific proposal on this over the weekend.
Gregg
More information about the DAS
mailing list