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


Dave,

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:drichards@trane.com] 
Sent: Tuesday, October 24, 2006 5:05 PM
To: Brian Frank; obix-comment@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
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]