Re: I object to the objection over object -> RE: Proposal to resolveinfo model issues

[Scott Hinkelman <srh@us.ibm.com>]

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.