[DAS2] [DAS] [Fwd: Re: Writeback implementation]

[Gregg Helt]

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