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
NIST Work: 301-975-3251
Bldg 820 Room 562 Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213
**************************************************************
