Hi I'm trying to define a set of rules for a logical delete commit and
have some gray areas that I'm not sure of.
*1. commit after delete flow*
[creation v1] => [modification v2] => [deleted v3] => ?
Can a modification/amendment v4 happen after a delete?
well, a deletion is a deletion, logically. In a non-versioned system, the
data object would literally disappear.
Logical deletions don't make data disappear, even if it's not under a
versioned system.
In a versioned system, such as we have, the top version records the fact
of deletion, which logically applies to the whole versioned object.
That sort of works on a lineal versioned system, the specs are not clear in
terms of how to handle a deletion in a distributed versioned system.
I agree delete should be considered to affect the status of the whole
versioned object, but on a branching scenario this is not so well defined
or maybe can't be implemented at all (see below ***).
The issue I see with versioning for deletion is that amendments,
modifications, etc. are defined at the same level of the deletions, and the
other modification types apply to the latest version, not to the whole
composition. Considering this: shouldn't delete be specified on it's own,
separated from other change types?
I always had doubts about using a commit to delete something, and now I'm
starting to understand why 
This is one of those cases that forks in the version tree can happen,
since v2 is deleted by v3, but v1 can be forked and a commit of
modification or amendment can happen on that branch.
it could, if in system A (say in hospital A), the Composition is logically
deleted but in system B (clinic B) a copy of that Composition (say
medications list) is modified with a new version; then if this modified
Versioned object is copied back to system A, system A will see a branched
tree, which communicates the fact that hospital A thinks the information is
no longer there, but clinic B does have a version of this information.
*** That kind of contradicts the "deletion logically applies to the whole
versioned object", since the versioned object is unique, independently of
which system has a copy of a version from that versioned object. On a
branching case, the delete seems to only affect a branch.
THis can only be resolved at the organisational level - i.e. by agreeing
what is really going on with the medication list (or whatever the info
object is) between the two HCFs.
Besides the delete case, that is the issue of merging branches, IMO is
always an organizational issue. We had another thread were we talked about
lineal vs. distributed/branching versioning.
But - is there any real scenario where this could actually happen? I can't
imagine System A really wanting to delete the medication list Composition.
Change medication list for X and I think we will have cases. If we don't
have cases, why do we included this on the specs?
A related issue, is if a delete happens by mistake, how can someone
"undelete" if no more commits are accepted on that branch after the delete?
I think it would be useful to accept commits, like amendment, because maybe
the data is not incorrect, but the previous delete commit was incorrect. In
that sense, when a logical delete happens on a system, a good feature is to
have a view of the deleted elements and allow users to undelete them, like
a trash bin.
IMO if delete can be executed by a user, undelete should also be executed
by a user, not by the organization.
I'm considering the delete only affects a VERSION, not the whole
VERSIONED_OBJECT.
Can a delete logically delete the whole VERSIONED_OBJECT?
that's what it logically means doing.
On a lineal versioning scheme, I'm not sure if an amendment can happen
after the delete. because the semantics of lineal versioning is I'm
versioning v3 not v1 if I do a commit after v3.
I think if a delete happens, that is like killing that branch, so no new
versions can be added.
Is that correct? What do others think?
well as you point out, things might be ambiguous if two systems modify
copies of the same versioned composition, and one of them does a logical
deletion. We probably need to think about this more carefully and update
the documentation. I at least would need to get a better understanding of
the problem first i.e. real use cases.
Rethinking that, I'm not sure if killing a branch is correct, since I see
the undelete case (mentioned above) happen if delete is allowed.
In terms of the spec, I'm worried about what the spec allows and try to
fill the blanks the spec doesn't provide. I'm not sure why allowing
something in the spec if we don't have use cases to support that. Maybe the
easiest would be to remove the delete cases from the spec and delegate that
to each implementation. Some may support it, some may support undelete,
some may apply the delete to the latest version, some may apply it to the
whole versioned object, others will support logical and physical deletes,
etc. There are too many cases to define all of them in an unambiguous way.
*2. delete on persistent compos*
Looking at the specs, it is not clear to me how a delete would affect a
persistent composition.
This is an open question.
This is also related with the previous case, since if a version is deleted
on a persistent composition, there will be more commits for it after the
delete, because it is persistent.
Well, deletion should really make the persistent composition act as if it
wasn't there, except for queries in earlier time windows. So I would say a
priori that further commits should be prevented, but - maybe someone is
going to say: what if the deletion was an accident? Maybe there needs to be
a lifecycle operation 'undelete' (or 'undo delete').
That is exactly what I was thinking of while writing
But! as I said, I'm not sure if delete/undelete should be handled at the
change type level, it seems to be a concept on a different level than
create/modification/amendment.
*3. delete a non-trunk version*
[creation v1] => [modification v2] => [amendment v3] => ...
Let's say there are many modifications/amendments for a compo, can be
persistent or event.
What happens if a version in the middle of the version tree/line is
deleted?
that can't happen - a deletion can only happen as the top version.
is that specified?
If we were talking about Git or some other typical system, deletion makes
it look like a file is actually gone, and subsequent commits will create a
new file of the same name, but whose version lineage is disconnected from
the previous one. We could add something to the spec to force something
like that behaviour.
In Git, If I checkout v2 on a new branch, and there are v3, v4, ..., in the
master branch. If a file is deleted on the new branch, and I commit the
branch, the file won't be there for that branch, and master (v3, v4, ...)
won't notice about that. All issues will happen when I try to merge my
branch with master, there I need to decide if I keep or not the file that
is a difference between the two branches.
The real issue here is now to merge, not the delete itself. But, the
semantics of a delete happening on a branch should be specified.
I think most implementation won't implement merging, so this case might not
happen. But if the specs support branching, the merging process and
handling deletions on branches while merging should be specified.