RE: [obix-comment] Contract inheritance

["Richards, Dave" <drichards@trane.com>]

>If the  contract has children with hrefs, then those children can be used
>as contracts themselves which seems to be a different problem than
>inheriting hrefs.  Or maybe I misunderstood your question?

No misunderstanding.  That was exactly my comment.  The children can be used
as contracts themselves (referred to hereafter as internal contracts) when
children href's are specified in the contract.  The obvious place these
contracts would be used is in the instances implementing the top-level
contract.  If the children parts of the instance are not addressable (no
href inheritance), what is the point of having them be types?  I believe it
is morally wrong to apply an internal contract to an object that is not a
child of an object conforming to the parent contract.  Of course, that's
just philosophy and there is certainly room for disagreement.

So my question then is: Is there some way other than href inheritance to
accomplish the goal of knowing all the addressable parts of an object based
solely on type information (gotten from a reference) without requiring a
client to query every instance?

The idea would be to use a facility similar to the BACnet object list to
obtain a list of references to objects and based solely on that knowledge be
able to query parts of the objects.
 
The comment about addressing being an implementation detail rather than a
contract detail is interesting.  I believe that you should have a choice and
that if you choose to make it a contract detail then there is no issue with
"uninheriting" the addressing.  If the contract says that children are
addressable then they must be addressable.  You would have to define a
similar type with non-addressable children if you wanted instances without
addressable parts.

In any event, I believe you understand the issue well enough, so you can
decide whether further discussion is warranted at this point.




>Regarding ref elements, the "is" attribute of a ref denotes the contract of
>what the ref points to.  Maybe this isn't spelled out very well, although
>the spec uses this feature itself for Lobby.about:

That's what we were looking for - the spec does not call that out explicitly
and should.




Dave Richards
drichards@trane.com