Hello, I have noticed a writeback thread in the mailing list and read it with a big interest. I agree with most of the ideas expressed by participants. The writeback specification was quite uncertain at the time when I was implementing it, and the aim of my project was rather to prove the concept. In principle it was proved, and writeback could be implemented in the real-life. However, the writeback specification needs to be more concrete.
1)about response to a writeback command. The response was a simple confirmation, it did not contain features, because writeback was not so complex. It saved exactly as "here's what I want to do". If the changes were successfully saved into the database, a simple confirmation was enough. Otherwise nothing was saved and a full error description was sent back. The source code can be found here http://code.google.com/p/daswriteback/source/browse/trunk/servlet/src/uk/ac/sanger/DatabaseUtilities.java 2)about URI. It is correct that "every feature in DAS/2.0 has a unique URI". For simplicity I did not include it into the writeback document, but it would be good to have it in the real implementation. 3)meta-annotations could simplify many things and add more functionality >> <FEATURE uri="http//my.server/feat123" ... > >> <PROP key="my_thoughts" value="overexpressed in tissue XYZ" /> >> <LINK href="http://somewhere.else/feat123"; rev="meta-annotation" /> >> </FEATURE> Best regards, Asia > Gregg Helt wrote: >> On Fri, Oct 31, 2008 at 7:22 AM, Andy Jenkinson >> <[EMAIL PROTECTED]>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. > > I looked at the DAS2 spec, but I was wondering specifically about Asia's > implementation - whether it did the same or returned either a simple > confirmation or a DAS 1.53 features response. > _______________________________________________ > DAS2 mailing list > [EMAIL PROTECTED] > http://lists.open-bio.org/mailman/listinfo/das2 > _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
