|Subject:||RE: [obix-comment] Contract inheritance|
|From:||Brian Frank (bfr...@tridium.com)|
|Date:||Oct 25, 2006 8:16:46 am|
After some more thought, I think I'm opposed to making hrefs inherited (although open to pursue it if you think it is really important). There is definitely merit to the concept, but I think the complexity outweighs the benefits. My philosophy is that addressing should always be an implementation detail, and never a contract detail. Otherwise we need to come new rules for dealing with various conditions: - inherit children hrefs, but not root - how to un-inherit href if the child isn't directly addressable
I'm not sure what you meant by the statement "Child href's in the type contract essentially defines subtypes, and these would not be very useful if the corresponding part of the instance were not addressable." 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?
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:
<obj href="obix:Lobby"> <ref name="about" is="obix:About"/> <op name="batch" in="obix:BatchIn" out="obix:BatchOut"/> <ref name="watchService" is="obix:WatchService"/> </obj>
-----Original Message----- From: Richards, Dave [mailto:dric...@trane.com] Sent: Tuesday, October 24, 2006 5:05 PM To: Brian Frank; obix...@lists.oasis-open.org Subject: RE: [obix-comment] Contract inheritance
Yes, it was the children that I was thinking of. I agree that you may not want to impose addressing on inherited types, and you certainly don't have to do so. You can leave out child href's on the type contract and force the instances to add them. It seems unlikely that you would add child href's in the type contract but want to remove them from the instances. Child href's in the type contract essentially defines subtypes, and these would not be very useful if the corresponding part of the instance were not addressable.
The root href is slightly problematic since you don't ever want the type href to be inherited by an instance. This won't be a problem on top level objects since the instance will typically define a new href value, but for transient or child objects it would be an issue. The convention would have to be that the top level href is not inherited.
If you have a device with a large number of instances of a particular complex type that happens to have addressable parts, it would be nice to be able to know the relative addresses of the parts based on the type contract so you don't have to read each instance in it's entirety to determine how to fetch the parts (or determine if there are parts that can be fetched).
Which brings up a point regarding the "ref" element. It would be helpful to have a "refis" or redefine "is" for a ref element to indicate the contract(s) for the referenced object. Having only URI's is limiting since I can't do anything until I've gone and read the object to find out what it is.
Dave Richards dric...@trane.com
-----Original Message----- From: Brian Frank [mailto:bfr...@tridium.com] Sent: Tuesday, October 24, 2006 10:46 AM To: Richards, Dave; obix...@lists.oasis-open.org Subject: RE: [obix-comment] Contract inheritance
The root's href should not be inherited because it is the public identifier for the contract.
But I think your question is related to the children of the root, perhaps something like this:
<obj href='Person'> <str name='firstName' href='firstName'/> <str name='lastName' href='lastName' /> </obj>
Is that what you are asking - such that instances of Person inherit the hrefs for firstName and lastName?
I think I like that, although the major downside is that it requires all implementations of the contract to support addressing down to the children. Personally I think of href as part of the "value side" rather than the "contract side" because it's a server implementation detail.
What was the rationale for not inheriting href's in contracts? Since the non-root href's will be relative, it would seem to simplify matters if they were inherited. That way derived types would not have to override elements simply to assign/reassign href's.