I think for individual problem domains you
just have to strike a balance between flexibility versus strong typing.
In general though a proliferation of optional features versus a proliferation
of contracts isn’t any different. We should use the type system
only to the degree in which is practical. For example often times is quite alright to just not implement features of a contract or interface. For
example it is common in OO libraries to throw a not supported exception if you
don’t support a specific feature. In fact oBIX defines just such an
error contract, obix:UnsupportedErr.
Unfortunately Bob you missed the rather
long multi-year discussion on how much to put into XML schemas versus how much
do within a fixed schema. In the end, to allow high fidelity with vendors
native systems, doing everything with custom schemas would have resulted in “schema
explosion”. It would have resulted in a tremendous
amount of complexity, and we just couldn’t find a way to make XML schema
do what we needed. So the compromise is to have a small fixed schema that
everyone knows how to parse, and define higher level abstractions using
contracts – but all oBIX documents
always conform to the fixed schema. I like to relate it to a programming language
– every time I add a new class
in Java or C#, I do so within the existing grammar of the language – I don’t
have to modify the compiler every time
I want to add a new class.
I would be happy to fill you in on the history
of that discussion either off-line or we can do it on the next conference call.
From: Aaron Hansen [mailto:ahansen@tridium.com]
Sent: Thursday, March 02, 2006
4:12 PM
To: obix-xml@lists.oasis-open.org
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