Re: V1.0 bug: Missing Undeprecate?

[David RR Webber <Gnosis_@compuserve.com>]

Len,

Excellent comments - I support everything!  And especially this note
(below) on "update insitu".

Also - in a production system - not just the backend class libraries - 
the librarian management side of course needs to give
visibility into current status of content - so that the librarian can
correctly approve submitted change requests and ensure they
are accurate and not conflicting.

"Delete" action I always saw as "not allowed" in the registry model - as
all semantics have to be retained - but deprecated as needed.
Resurrecting items after extended such demise should be done 
with caution to avoid the "zombie" effect of ghosts in the machine!

Clearly the most common use case is when someone deprecates
something by mistake and needs to immediately restore it.

Thanks, DW.
=========================================================
Message text written by Len Gallagher
>A submitting organization 
will not easily be able to delete a RegistryEntry instance and replace it 
with one with modified attributes, because the RegistryEntry instance will 
be linked to too many other things that can't live on their own during the 
replacement process.

I think we should consider a general purpose ModifyRegistryEntry service 
that would allow a submitting organization to modify the SO-supplied 
attributes of existing instances of the RegistryEntry and ExtrinsicObject 
classes without having to delete and then re-establish all of the 
classifications and associations linked to those instances.
<