[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC