OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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
drichards@trane.com


 

-----Original Message-----
From: Brian Frank [mailto:bfrank@tridium.com] 
Sent: Tuesday, October 24, 2006 10:46 AM
To: Richards, Dave; obix-comment@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.

Brian


-----Original Message-----
From: Richards, Dave [mailto:drichards@trane.com] 
Sent: Tuesday, October 24, 2006 11:23 AM
To: obix-comment@lists.oasis-open.org
Subject: [obix-comment] Contract inheritance

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.

 

 

Dave Richards

drichards@trane.com <mailto:drichards@trane.com> 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]