[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]