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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Regrep site update

I've updated the member's-only site with a diagram from Len
Gallagher of NIST, who describes it as follows (emphasizing
that it's not a NIST proposal):

Attached is a 1-page PDF file showing a Relational Rose UML diagram for a
portion of the OASIS RegRep specification. It's at a slightly higher level
of abstraction than our relational diagrams and thus may give a clearer
picture of the important concepts.

I used only the subset of UML recommended by MOF (Meta Object Facility from
OMG), so theoretically, it could be accessed by MOF utilities or
transferred automatically to an XMI description and an XML representation
that could then be shared with other MOF metadata implementations. The rest
of our RegRep implementation model could be quite easily re-written in this
UML form, but I don't see any immediate advantage in doing so, since MOF
access and manipulation tools are still in a very early stage of
development, and we're doing a relational implementation anyway.

This is primarily for your information since I know that your RegRep group
is toying with the idea of doing a UML specification for the
registry/repository.  This is not a recommendation or a contribution from
NIST - instead, it's just an example of what a UML specification of the
OASIS Registry/Repository might look like.  It is a very easy step to go
from this design to our relational implementation.

A few conventions for the UML diagram attached: I used all UPPERCASE names
for classes having "persistent" instances, so they map nicely to relational
tables for persistent storage of the instances. They are identified
ByReference, so the relational table's primary key is the reference! For
example, the reference for a REGISTRY_ITEM instance will be the locally
generated RAitemId. Other clases have "transient" instances, e.g. URIref
and Representation.  They are defined to be referenced ByValue, so they can
always be 
embedded in the referencing class, or table, as a collection of attributes,
or columns, for persistent storage.

regards, Terry

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC