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: Re: Limits on ebRIM Generalizations




All,

I distributed an email to this Registry list earlier today that gave my 
take on the pending proposal to restructure the ebRIM data model

   http://lists.oasis-open.org/archives/regrep/200108/msg00078.html

Attached is a "HelpfulUML" diagram to support the discussion.

This diagram is a specialized subset of the proposed ebRIM model. It is 
consistent with that model and does not violate any of its provisions. 
However, it chooses not to present some capabilities of the general model. 
Instead, it presents only those features that I believe should be required 
of all conforming implementations. It addition, it gives some of those 
features more visibility so that they can be highlighted by Registry Services.

1) Classification_RE is a specialized subtype of Classification that only 
classifies RegistryEntry instances.

2) Association_RERE is a specialized subtype of Association that requires 
both the sourceObject and the targetObject to be RegistryEntry instances.

3) HasExtLinks is a specialized subtype of Association that highlights 
one-to-many associations from a RegistryEntry instance to zero or more 
ExternalLink instances.

4) HasExtIdentifiers is a specialized subtype of Association that 
highlights one-to-many associations from a RegistryEntry instance to zero 
or more ExternalIdentifier instances.

The existing FilterQuery specification of RegistryEntryQuery in the 
Registry Services document (ebRS Section 8.2.2) is based on this diagram.

NOTE: In my opinion, the major attraction of using this UML diagram over 
the more general ones is that every UML association pictured in the diagram 
is either a single-valued UML association or a one-to-many UML association. 
This makes it straight-forward to visualize an XML representation of the 
content as a nested tree structure supported by the XML Document Object 
Model (DOM). The FilterQuery approach also uses this implied tree structure 
as the basis of its definition. All joins among classes are implicitly 
invoked by nested XML clauses -- there is no need for the user of 
FilterQuery to struggle with explicit join conditions among classes. This 
means that the class identifiers for some classes (e.g. Classification_RE 
and Association_RERE) need not be visible! Thus an implementation need not 
statically store superfluous 128-bit UUID's for those classes.

-- Len

HelpfulUML.pdf



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


Powered by eList eXpress LLC