Re: V1.0 bug: Missing Undeprecate?

[Len Gallagher <LGallagher@nist.gov>]

All Registry folks,

I agree with Farrukh that we are missing a service to modify the status 
attribute of a RegistryEntry instance from "deprecated" to "undeprecated". 
But "undeprecated" is not a valid status -- instead, what we really need is 
a service to modify the "status" attribute of a RegistryEntry instance.  Or 
better yet, a way to modify any SO-supplied attribute of a RegistryEntry 
instance, including: objectType, status, userVersion, stability, 
expirationDate, name, description, and contentURI, mimeType, and opaque if 
the RegistryEntry instance is an ExtrinsicObject instance.

Right now, the only Registry Services we have to manage the attributes of 
objects are the services found in Section 7 of the Registry Services 
document. These include:

   SubmitObjects
   AddSlots
   RemoveSlots
   ApproveObjects
   DeprecateObjects
   RemoveObjects

For all classes except RegistryEntry, ClassificationScheme, and Package, I 
think we can get by with just the SubmitObjects and RemoveObjects protocols 
(or special services like we have for Slot for classes that do not require 
GUID's). With create and delete actions, one can add and remove 
classifications, associations, external links, and external identifiers. 
Since these classes have very few independent attributes and very few 
associations with any object other than their parent RegistryEntry 
instance, we can survive in the short term with just create and delete 
capabilities.

But the RegistryEntry class is different. It is the base class for the 
metadata of a repository item and it has a much larger set of attributes 
under the control of the submitting organization. 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.

Focus attention just on the "status" attribute of a RegistryEntry instance. 
 From Section 7.3.1 of RIM it has the following possible values:

   Submitted
   Approved
   Deprecated
   Withdrawn

I anticipate additional "status" alternatives when non-ebXML organizations 
use the Registry model for their own purposes. Other "status" candidates 
are: "underReview", "superceded", replaced", etc. We need to provide a 
general service to allow changes in status -- not just a specialized 
service to "deprecate" or "undeprecate" the repository item. We also need 
rules in the model to identify which "status" values can be set by a 
submitting organization and which are completely under the control of the 
registration authority.

And the RIM needs to specify which of these actions are Auditable Events.

-- Len



At 07:47 AM 8/17/01, Farrukh Najmi wrote:

>This is a repost as it was posted to the wrong list earlier.
>
>We have a way to deprecate objects in the interface. We do not have a
>way to undeprecate a deprecated object. I believe this issue needs to be
>
>logged and treated as a simple must-fix bug for V2.0. The solution is
>fairly obvious: add an undeprecateObjects method and an
>UnDeprecateObjectsRequest in ObjectManager.
>
>What does the team think?
>
>--
>Regards,
>Farrukh

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************