[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