RE: [obix-comment] Contract inheritance

["Chaudhari, Hemraj" <HChaudhari@trane.com>]

Hi,

I would like to add something to this discussion.
1) I would like to view bac:AnalogOutput as definition and /someAOs/1 as
implementation of contract. like defining class and creating an instance of
it.

2) When one contract is inheriting other contract derived contract is bound
to provide some href. E.g. <obj href="contract1">
  Hundreds part with href
</obj>

<obj href="contract2" is="contract1">

</obj>

There is no problem of inheriting href for root in derived. Derived will
always have its own href.

Here "contract1" and "contract2" are not really href. But they are name of
the contracts (new type). I am not sure why oBIX used href to name
contracts.

If contract2 is inheriting 100 parts with href, do I need to repeat
(override) those inside contract2 just to make them addressable. In this is
a case we are getting little by inheritance. 

3) My guess is relative href works with href of parent(in mail its said that
it work with root). 

4) In implementation of contract if we want to make subpart addressable we
are bound to provide href. href="1" & href=2" in our case. 


Regards
Hemraj Chaudhari.




-----Original Message-----
From: Brian Frank [mailto:bfrank@tridium.com] 
Sent: Wednesday, October 25, 2006 11:38 AM
To: Richards, Dave; obix-comment@lists.oasis-open.org
Cc: Aaron Hansen
Subject: RE: [obix-comment] Contract inheritance

Regarding your first paragraph, what you are calling "internal
contracts" to me are like Java inner classes or nested types.  So I
don't see them as morally wrong - but then again I don't really see that
as something commonly done.  As an example I could have defined
obix:About as a nested contract within obix:Lobby.

Your real issue is learning addressing information from the contract,
and I see how that is an important issue we should discuss further.  But
let me postulate an example which I think is in your head:

  <obj href="bac:AnalogOutput">
     <real name="present_value" href="present_value"/>
  </obj>

In the contract above it is desirable to know that present value is
always addressed using the relative href "present_value".  But you
probably see the problem if I use that contract in an instance document:

  <obj href="/someAOs/">
    <obj name="ao1" href="1">
      <real name="present_value" val="44"/>
    </obj>
    <obj name="ao2" href="2">
      <real name="present_value" val="77"/>
    </obj>
  </obj>

According to everything we've done to date all relative hrefs are
resolved relative to the root href.  Now we've introduced a tricky
situation where the inherited hrefs have to be resolved relative to the
object implementing their contract.  Furthermore by omitting the hrefs
of the present values I've taken away valuable information to
non-contract aware clients for the sake of making the XML smaller (which
of course is it's own philosophical discussion).

Those are just my initial thoughts, but neither do I think we should
dismiss this issue out right.  I suggest we setup a call to debate this
issue, although a change like this would require holding up review
process.

Brian


-----Original Message-----
From: Richards, Dave [mailto:drichards@trane.com] 
Sent: Wednesday, October 25, 2006 12:04 PM
To: Brian Frank; obix-comment@lists.oasis-open.org
Subject: RE: [obix-comment] Contract inheritance

>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


This publicly archived list offers a means to provide input to the
OASIS Open Building Information Exchange (oBIX) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: obix-comment-subscribe@lists.oasis-open.org
Unsubscribe: obix-comment-unsubscribe@lists.oasis-open.org
List help: obix-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/obix-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix