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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

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

Subject: Information Model Hierarchy: Take 3

Below is an inheritance diagram with my current thinking on the Information Model. I relaize it is too big to print decently. It is a minor evolution of what I posted previously on behalf on Len and I in previous weeks. The remainder of this note decsribes the rationale behind my thought process and is folowed by open issues. An important aspect is that this note defines the rules I have used to lay out the classes and attributes in the model.

I humbly request that this straw dog proposal to be discussed in a phone conference that Scott may setup for this week.


What Is An Object

This section decsribes the criterea defined for determining whether some data is an Object or not.
Instances of Object provide a meta-model for registry content: Initially Object was modeled to only have the GUID attribute. Later I added the description attribute after observing that all its sub-classes had needs for something akin to a description (e.g. comment in Submission). It seemed reasonable that all Objects have the option to be self describing.

What Is Not An Object

Note that Address and Contact are classes that are not Objects. An Address or a Contact does not have its own independent existence (and consequently no identity). They are simply wrapper classes whose purpose is to group a set of attributes into a new reusable type. The new type may be used in multiple classes in the model as needed.  They are always part of some other Object (e.g. instances of Organization).

What Is a ManagedObject

This section decsribes the criterea defined for determining whether some data is a ManagedObject or not. The confusion in this area arises from the folowing distinctions being blurred:
  1. Distinction between meta data about a submitted content (e.g. version ifno) and the submitted content itself. To resolve this confusion we simply state that ithe info model has no classes to model a submitted content (referred to in spec as managed object content). So we are always dealing with meta data about managed object content in teh model
  2. Distinction between the typical submitted content (e.g. Party profiles, business process descriptions, schemas, etc) and other submitted content such as (Association, Classification, ClassificationNode, ExternalObject. To resolve this confusion we have added the classes ExtrinsicObject and IntrinsicObject as sub-classes of ManagedObject as will be described later.
  3. The special nature of the Submission and Organization classes. These will be discussed later after the normal cases have been worked through so they dont muddle the issues prematurely.

What Is an ExtrinsicObject

An ExtrinsicObject Content provides a meta-model for content whose type is not intrinsically known to the Registry. Since the Registry can contain arbitrary content without intrinsic knowledge about that content, ExtrinsicObjects require special meta data attributes to provide some knowledge about the object (e.g. mime type). Examples include Party profiles, business process descriptions, schemas, etc.

What Is an IntrinsicObject

An IntrinsicObject  provides a meta-model for content whose type is known to the Registry. These types are well known and in fact defined by the registry specifictions. Examples include Association, Classification, ClassificationNode, ExternalObject, Organization and Package..

Characteristrics of ManagedObject

Some characteristrics of ManagedObject follow. Instances of ManagedObject:

What Is Versionable

Any class or interface in the model that is required to support teh ability to create and maintain multiple versions is Versionable. The Versionable interface has been factored out of ManagedObject to give us some freedom to decide what classes are Versionable or not. Currently only ExtrinsicObjects are Versionable. It is an open issue whether IntrinsicObjects also need to be Versionable. I feel they should have the option. I believe Len disgarees. Not that any class or interface in teh model that implements the Versionable interface in addition to other inheritance links is not suffering from evils of multiple inheritence. Versionable is an interface not a class. Inheriting from an interface simply enforces behaviour (method) conformance.

Deciding What Goes Under Which Class

Now that we have defined the rules for what is an Object etc., we can apply these rulese as consistently as possible to determine which info model classes get sub-classed from which base classes. There are some exceptions that will be treated as exceptional cases.


  1. Should Versionable be implemented by ManagedObject instead of ExtrinsicObject. Alternatively should it be implemented by both ExtrinsicObject and IntrinsicObjects. My vote is to have it be implemented by ManagedObject. Gives the most flexibility.
  2. Should ExternalObject be derived from Object. I feel better leaving it derived from IntrinsicObject. This follows the rules and is not an exception. It also gives most flexibility.


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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC