RE: I object to the objection over object -> RE: Proposal to reso lveinfo model issues

[Rebecca Reed <rreed@mercator.com>]

 I have not previously expressed an opinion about objects, components,
metadata, etc.

I believe that objects is an OK term to use because while it implies a noun
with attributes it has evolved to include behaviors and actions.  

A component is a more general term that can be a noun, an action, or any
combination of these including attributes.

The purpose of defining objects in terms of metadata was to allow set theory
to prevail - an object can be a part of one or more other objects and may or
may not contain other objects.  Objects in this context have attributes,
nouns and verbs as requied.  Object use is not hierarchical except in the
particular inclusion within a particular instance of a set.

Any object (or component) that describes other objects is metadata.  A
registry serves as a mechanism for structured pointers to where information
is stored and thus is metadata.  The purposes of registries are varied and
need to be defined for each registry, including ebXML.  The places to which
registries point are repositories.  Repositories may include metadata or
simple elements - again depending on how the repositories are defined and
meant to be used.  In the simplest instance a repository may be a database
of elements or a URL.  Again the ebXML repository functions and uses need to
be defined.  If the ebXML repository contains information about data then it
also contains metadata.  

Whether we use the word "object" or "component" is not important - rather
the description of how the word is being used by ebXML is what matters.
However, given the muddiness and varied use of the word "object", I would
probably vote for the word "component".  Use of components in place of
objects has a more general application and less confusion about
interpretation in my opinion.

Now for the disclaimier - this is the first opinion I have expressed.
Please disregard my comments if they are not in line with the general
thinking of the group.

Regards, Becky Reed
-----Original Message-----
From: Scott Hinkelman
To: Nieman, Scott
Cc: ebxml-regrep@lists.ebxml.org
Sent: 12/6/00 10:28 PM
Subject: Re: I object to the objection over object -> RE: Proposal to
resolve info model issues

I still do NOT fully understand the objection over the object class or
ManagedObject.

I follow the philosophy that everything and anything is an object.  I
heard
"behaviour" being a factor in this on the last teleconference, plus a
product-based issue.

<srh>If following the "everything" is an object as a baseline,
(which I do not think this way in either programming or Architecture)
then why would you agree to explicitly having an "object" class? On this
one,
I like Len's suggestion to change it to something that indicates a root
that
has some meaning to the Registry.

<srh>I still have concern over "ManagedObject" due to IBM's
ComponentBroker
which uses that term. So I support changing it, and Len's proposal is
fine
with me, and in the name of cycles spent, this is the last you will here
this
from me.

1) An object CAN have behaviour, but it does not mandate that is HAS
behaviour.  A rock is an object and has no behaviour.  To insist that
objects have behaviour forces the rock to have an operation such as
throwMe() which is nonsense.

I agree. This is refered to by many programmers as "structified
objects".

2) I do not believe that it really conflicts with any programming model
if
it is properly namespaced. ebxml.registry.object whatever.

I also argued that objects can contain other objects, which to me is a
critical concept.

<srh>In software, structures and contain structures also.

I would like a vote to see if there a consensus to any change to this.
I
vote no change!

<srh>My "vote" is to changed ManagedObject to anyhting else.

If I am missing a major point, please help clarify this position.  I do
not
want too many cycles put on this topic.

Scott

>> BTW What do folks think of renaming Object to Identifiable? The idea
is
to factor out behaviour such as Identifiable Versionable etc. as
separate
classes so that behaviour can be added at any level. The Identifiable
class
would still have the GUID attribute as its only attribute. This may
partially mitigate Scott H's concern about Object.

<srh>Farrukh, I am not at this moment in front of the info, but
factoring
out mixin behaviour like Versionable,
and Identifiable is a good modeling technique that we have have much
success with in complex projects,
so I support this thinking.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Nieman, Scott" <Scott.Nieman@NorstanConsulting.com> on 12/06/2000
12:02:20
PM

To:   ebxml-regrep@lists.ebxml.org
cc:
Subject:  I object to the objection over object -> RE: Proposal to
resolve
      info model issues



I still do NOT fully understand the objection over the object class or
ManagedObject.

I follow the philosophy that everything and anything is an object.  I
heard
"behaviour" being a factor in this on the last teleconference, plus a
product-based issue.

1) An object CAN have behaviour, but it does not mandate that is HAS
behaviour.  A rock is an object and has no behaviour.  To insist that
objects have behaviour forces the rock to have an operation such as
throwMe() which is nonsense.

2) I do not believe that it really conflicts with any programming model
if
it is properly namespaced. ebxml.registry.object whatever.

I also argued that objects can contain other objects, which to me is a
critical concept.

I would like a vote to see if there a consensus to any change to this.
I
vote no change!

If I am missing a major point, please help clarify this position.  I do
not
want too many cycles put on this topic.

Scott

>> BTW What do folks think of renaming Object to Identifiable? The idea
is
to factor out behaviour such as Identifiable Versionable etc. as
separate
classes so that behaviour can be added at any level. The Identifiable
class
would still have the GUID attribute as its only attribute. This may
partially mitigate Scott H's concern about Object.