|
First,
thanks to Toby, I think this message will go through. I have many mail aliases
at Echelon and Toby figured out that the email address I registered with at
Oasis was not the one that outlook put on my emails. If this works, all's
well.
Now
onto Brian's comments.
I have
no interest in rehashing the past. What I've been trying to do in a short time
is to verify that the proposed oBIX kernel can be extended and grow to meet the
needs in the various vertical markets that we participate in. To that end, I've
been trying to discover how best to build on top of the kernel. One difference
beween the proliferation of contracts and using SOAP is that the contracts and
contract location and contract revision issues seem to be client side issues,
while a WSDL on a server has the potential to just take care of the clients by
serving fully self described objects. Having said that, both alternatives have
the same order dependency. In either case, EITHER first you read the WSDL,
then you use the web services OR first you get the contracts, then you parse the
oBIX data. Operationally they could be similar. When I read section 5.1 of the
0.9 draft, it seems to me that a contract could, in fact, be a WSDL file. Then,
if the client always went to the oBIX server to get the contracts and the
contracts were WSDLs one would have the benefit of any browser that knows SOAP
being able to get and render oBIX data. Now, if oBIX isn't meant for browsers
and GUIs then this doesn't matter as much, but I'm thinking with all the SOAP
aware clients, this may be a good capability. Do you believe such an extension
is possible within the current oBIX definition?
-bob
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
|