ebxml-regrep message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Gallagher - Comment/Proposal #2, "Retain the notion of Repository"


Gallagher - Comment/Proposal  #2, "Retain the notion of Repository"

DISCUSSION

When other ebXML groups think of the Registry/Repository, I'm sure they
think of it as the place where the objects they are interested in can be
stored and described. The storage is the Repository part and the
description is the Registry part.

Early in October (10/4/00) I distributed a 1-page diagram to this email
list showing what I thought was a reasonable representation of both parts
of a Registry/Repository implementation. This diagram allows one to make a
clear distinction between objects that are submitted to a
Registry/Repository for safekeeping and associated, but distinct, metadata
objects used to describe the submitted objects, their classifications, and
their relationships to other registered objects.

The 1-page diagram is again attached as a PDF file. The part circled in
Blue is the Registry part and the remainder is the Repository part. In some
cases, certain objects are visible to Registry Servcies (e.g.
ClassificationScheme and RegistryPackage) even though they are really
registered objects, not metadata about a registered object. Instead, they
have their own registry entries to describe them. These objects are
"special" in that there will be special registry services defined to create
and access them.

I understand that the face-to-face meeting in Tokyo decided to remove all
references to Repository from the Registry & Repository Information Model.
Why?  Isn't one of the requirements of a Registry/Repository to provide a
storage facility for safekeeping of registered objects. They are NOT
metadata - they are the "managed object content" - so how should they be
viewed by the ebXML Information Model.

I believe that Repository should have a role in the Registry/Repository
Information Model, even if the Registry Services do not provide direct
access to Repository content. The role may simply be the "container" where
all registered objects are kept for safekeeping.


PROPOSAL

Re-institute the notion of Repository as an optional component that is part
of a Registry/Repository implementation. Use the attached UML diagram as a
reasonable way to picture the relationships between RegistryEntry and
RegisteredObject instances in an ebXML Registry/Repository.

One can still make it clear that the only access to the Repository is
through the URI provided as the objectLocation attribute of a RegistryEntry
instance, or as a special Registry Services interface to get a registered
object based on its object reference.

ebxmlUML.pdf

**************************************************************
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]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC