[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: V1.0 bug: Missing Undeprecate?
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 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC