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: RE: Proposal to resolve info model issues

1) I am somewhat troubled by Associations and Classification not inheriting
from ManagedObject.  for example, I use associations to create a package of
ManagedObjects, and by removing an association (deprecate, or delete), a
ManagedObject can be removed from a package, but is NOT removed from the
Registry.  Therefore I am managing associations.  It is an IntrinsicObject
too, since associations are critical to the nature of a registry (if I am
intrepreting this correctly).

I have had concerns about the Contact, Organization, and Address classes not
inheriting from ManagedObject too, since there are subject to versioning ,
but I am less concerned about those classes as I am about associations.  the
begging question is when I update address information, do I replace it or
version it?  ditto with contacts etc.

2) I am happy with modeling the concepts of extrinsic and intrinsic, versus
debating whether we are modeling the repository. I believe there is no
benefit adding a class for the ACTUAL content in a repository, since the
metadata ABOUT the content is more than sufficient and should give me a
"handle" to the actual object when I need it (to download, to parse, etc).
I believe a classification is an extention of the metadata, further
describing the ManagedObject. 

3) I perceive there is still a conceptual difference between Classification
Scheme and Classification.  To me, a classification scheme is special
ManagedObject that consists of classification nodes, and Classification is a
special link between a ManagedObject and a classification scheme (e.g.,
linked to a specific node within the scheme).  If we are trying to equate
the two concepts, we need to explicitly state how classification
accomplishes the representation of a scheme.  I strongly believe as you try
to clarify that, that you will see my point in issue #1.



-----Original Message-----
From: Farrukh Najmi - JavaSoft East [mailto:Farrukh.Najmi@East.Sun.COM]
Sent: Monday, December 04, 2000 12:10 PM
To: ebxml-regrep@lists.ebxml.org
Subject: Proposal to resolve info model issues

Hi Team,

Len and I have been working to get our ideas to fit together. Here is the
current thinking on the chanhes needed on the info model. Please see
GIF file for reference:

Based on Friday's discussion we had identified the need to model two types
Registry Content (as meta data). Note names were given today:

1. IntrinsicObject: Sub-class of ManagedObject that provides metadata on 
content that is known to the Registry

2. ExtrinsicObject: Sub-class of ManagedObject that provides metadata on 
content that is not knownn intrinsicaly  to the Registry

For dictionary definition of intrinsic and extrinsic see:


Note that not all Registry content known to Registry is derived from
since some have minimal metadata requirements and are derived from Object.

Note that:

-Object only has GUID attribute now.
-major and mindor version are now in Versionable
-ManagedObject has registryStatus, description and submission
-ExtrinsicObject have url, name, type and mimeType
-IntrinsicObject has no attributes identified so far

Please note that this is a joint proposal by Len and I and naturally we are
in agreement on this. There may be some details to iron out but there is a
strong desire and ability for us to work as a team and get through these
in teh next few week. 

Lets all work hard to make the Jan 12 drop dead deadline for all our Release
spec work to be submitted to QR so we can all be proud of what we have


Len and Farrukh

[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