Hi Gavin! Thanks for your comments!.
> On 26/11/2010 16:48, Erik Sundvall wrote: >> http://www.imt.liu.se/~erisu/2010/EEE-Poster-multipage.pdf On Sat, Nov 27, 2010 at 17:36, gjb <gjb at crs4.it> wrote: > I've been experimenting with the eXist.org DB that lets you GET and PUT > (and version) hierarchical records (XML) RESTfully to & from the browser > without any intervening layer (unlike PHP etc). We have also been using eXist as one of the (so far three) tested configurable XML databases in LiU EEE. We want to make sure that EEE is not too tightly to any particular database solution, since the best choice will differ depending on e.g. your major usecases, system environment and load. > It works well for my non EHR web-app - that uses jQuery to tame > my in-browser code. We assume that jQuery will be one of many options that people will use for building GUIs connected to the "Contribution builder" resource that you see in the poster. GWT with added restlet support is another interesting option, so is Flash/Flex or any other http-speaking GUI framework. A nice thing with the web is that you can mix and integrate many of them in the same GUI if you want to reuse other people's implementations. One of the intentions of having a separate "Contribution builder" resource is to make it even easier. > It probably not industrial-strength but the eXist way has plenty of > standards based ways of getting things done > - including xQuery pipelines incorporating user specified Java modules. xQuery is what we currently translate AQL queries to before they are executed in eXist or other xQuery-enabled databases (like e.g. Sedna [1], BaseX [2] or Oracle's XML products). xQuery's semantics seems powerful enough to cover what we need from the AQL semantics. But again, we don't limit EEE to xQuery and XML databases, it was just a convenient start and a reasonable option for the use case where you from e.g. web browsers often want to access entire openEHR COMPOSITIONS serialised as XML via http. For advanced population-wide queries we believe other database backend solutions will be preferable, but we have aimed for a design where the same basic REST interface can be reused by such clients. > could be something to consider. See above :-) > BTW I doubt there's much usage for HTTP DELETE for audited EHR. > > Gavin Brelstaff I agree that DELETE will not be used on the committed "Contribution" or "Versioned object" resources you see in the poster - if that is tried then a http 405 "Method Not Allowed" [3] error will be returned. The "Contribution builder" resource on the other hand _does_ allow HTTP DELETE since it is considered a personal temporary writing space where you might e.g. select the wrong forms/templates and want to correct that immediately while you are documenting, before you have committed. Note that openEHR does allow committing unfinished work however, e.g. when you have to rush of to another patient but what want to commit what has been documented so far. Such commits can be flagged as incomplete but are available as proper "Versioned objects" that can't be deleted, but rather updated to new more complete versions when there is time continue. Thus the design intention of "Countribution builder" is not to store incomplete data for long periods, only to act as a well specified interoperable writing space while actively composing. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 References 1. http://www.modis.ispras.ru/sedna/ 2. http://www.inf.uni-konstanz.de/dbis/basex/ 3. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6
