On 04/04/2016 19:14, [email protected] wrote:
Hi Thomas,
What about having the 'delta' mode just at the API level? Storage
might not store delta objects, just full objects, but the API allows
to send only what was added, modified or deleted instead of the full
compo?
then you have a transactional concept, i.e. 'add', 'remove', 'modify'
etc... so for me the better way to think about it isn't in terms of data
structures but in terms of logical changes to the existing state of some
Composition.
But the logical thing is just a function of the form
add (atPath: String; newObject: Locatable)
so then it's just a case of what level of domain semantics you want. For
example, you could have a function:
addEntryToComposition (atPath: String; newEntry: Entry)
so it's not far to get to:
addMedicationOrder (newMed: Instruction)
Now - we don't need a path, since the API knows we are dealing with a
MedicationList Composition (that should follow an archetype of that
name) and new medication orders (Instructions) only go in a certain place.
So you can take your pick - the great thing about APIs is you can have
as many as you like - as long as they all obey the same rules of data
structuring and validity.
If it makes sense in your environment to create an API of the flavour of
the first one above I say go for it.
- thomas
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
