[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [obix-xml] SNVT union example in oBIX
This was Bob's response to my last posting, for some reason OASIS doesn't like him.
I haven't had time to think this through, but I would say contracts are more a substitute for XML Schema that WSDL. And I think that is a seperate issue that how to model optional members of a union, maybe Brian can chime in...
-----Original Message-----
From: Bob Dolin [mailto:bobd@echelon.com]
Sent: Thu 3/2/2006 1:25 PM
To: Aaron Hansen; obix-xml@lists.oasis-open.org
Subject: RE: [obix-xml] SNVT union example in oBIX
You're on meds and I don't know much about Obix, we'll make a fine pair in this debate!
I think the problem is that you could have 2 manufacturers with two different cameras and only one not supporting zoom. So then you have 2 hrefs, qualified by manufacterer??? And when there is a third and a fourth camera with different options? It seems like the proliferation of contracts could be an issue.
In reflecting on this some more, it seems that contracts are a substitute for a wsdl. The beauty of the wsdl is that you get all the information you need in the contract with the object returned in the soap call, you don't need to go hunting around for the right contract. Was this point ever debated in the obix group?
-bob
-----Original Message-----
From: Aaron Hansen [mailto:ahansen@tridium.com]
Sent: Wednesday, March 01, 2006 2:56 PM
To: obix-xml@lists.oasis-open.org
Subject: RE: [obix-xml] SNVT union example in oBIX
Sorry about the last dupe. I am on meds, but honestly, I do stupid things like that all the time.
If I understand Bob's issue of optional members in unions, it's that the camera in Brian's example might allow pan and tilt but not zoom, and Echelon would like the oBIX server to be explicit about what optional members are supported. I think this problem can be explicitly modeled in oBIX without the use of another attribute. To make a long story short:
<obj href=""someCamera"" is="lon:PannableCamera lon:TiltableCamera">
<op name="pan" in="lon:PosCtrl"/>
<op name="tilt" in="lon:PosCtrl"/>
</obj>
Does this make sense and does it address the problem?
Best,
Aaron
-----Original Message-----
From: Brian Frank [ mailto:bfrank@tridium.com]
Sent: Wed 3/1/2006 2:50 PM
To: obix-xml@lists.oasis-open.org
Subject: [obix-xml] SNVT union example in oBIX
Jeremy promised a Lonworks union example, and I promised a proposal how
I would do that in oBIX. For now let's assume we do this completely on
top of the existing spec (we will discuss ways the spec could be changed
below).
In this example, a camera is told to go to a particular position. It
could be a pre-defined position that is denoted by a number
(SNVT_pos_ctrl.value.number), or by the coordinates
(SNVT_pos_ctrl.value.abspos.xxxx):
typedef struct{
unsigned long receiver_id;
unsigned long controller_id;
unsigned short controller_prio;
cam_func_t function;
cam_act_t action;
union{
unsigned short number;
struct{
signed long pan;
signed long tilt;
signed long zoom;
} abspos;
} value;
} SNVT_pos_ctrl;
In oBIX I would probably model this as three contracts; let's assume
these contracts are standardized within Lonmark using some
www.lonmark.org < http://www.lonmark.org/> URI with a prefix of "lon":
<obj href=""lon:PosCtrl">
<int name="receiverId" min="0" />
<int name="controllerId" min="0" />
<int name="controllerPrio" min="0" />
</obj>
<obj href=""lon:PredefinedPosCtrl"" is="lon:PosCtrl">
<int name="number" min="0" />
</obj>
<obj href=""lon:CoordinatePosCtrl"" is="lon:PosCtrl">
<int name="pan"/>
<int name="tilt"/>
<int name="zoom"/>
</obj>
I didn't fill in the max, but easy enough to do if important. Then I
might use those contracts for a camera object:
<obj href=""/SomeCamera">
<op name="moveTo" in="lon:PosCtrl"/>
</obj>
That's also probably how you would tackle that in an OO language like
Java or C# too.
Bob brought up another excellent point - if I'm a client how do I know
what the possible concrete implementations of lon:PosCtrl I have
available to me? If I was auto-generating a user interface then I could
use this to prompt the user for the correct choices. The simplest
solution is to just say "you can't" - the client and server have to have
agreed about what contracts are acceptable as part of some
specification. That actually probably covers a whole lot of practical
cases.
However, I think it very useful to think about how it could be taken
further. In a strongly typed, define everything up front solution I
would probably provide the list of contracts in another property as a
list or an enum. In a looser typed environment, it might be cool to let
a server answer questions about contracts like "tell me all the
sub-contracts which implement this contract". In my experience the
latter mechanism is immensely powerful and we use it extensively in
Niagara for dynamically binding types together (for example give me all
the editors you have on this type, or give me all the device types found
which work with this driver). Although my current thoughts are that it
premature to attempt a standardized kernel spec level solution.
Brian
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]