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


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

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

Subject: Re: [obix] Fear and Trembling and Contracts and Joy

This is analogous to saying (I think) that a particular contract MAY have a business context and rules that are out of scope for obix. The real issue is whether undefined things are carried along with obix objects (IMO not a good idea) or correlated in other ways (typical practice - e.g. a lookup table based on a contract ID).

There are many ways of doing that, so I think a simple note saying the above is sufficient.



William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

On 12/16/13 12:59 PM, Gemmill, Craig wrote:

Another thing about contracts is they may also have an implicit portion not captured in the explicit schema (“if you do this, the object implementing the contract must do that”).  Although this could possibly be expressed in some sort of textual description element.


From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Markus Jung
Sent: Sunday, December 15, 2013 10:33 AM
To: obix@lists.oasis-open.org
Subject: Re: [obix] Fear and Trembling and Contracts and Joy


This process sound quite good, covering extension to the contract library with committee notes.

Only one minor thing, it will not be possible to use XML schema files to describe contracts. Since contracts are defined by example (templates) as regular OBIX objects, which mean that these files will be standard XML files adhering to the XML core schema.


Am 12.12.2013 23:28, schrieb Toby Considine:

I was both happy and wary after today’s meeting on contracts. An agreement to have OASIS host a set of standard contract libraries was a wonderful thing. The suggestion that we might get them from a variety of new sources was interesting. The prospect of voting on standard contracts for the next 5 years was daunting, to say the least.


I just got off the phone with Chet Ensign, the head of managing the TC process for OASIS, and he suggested a path that reduced my wariness. If it meets the needs of the TC, we can proceed. First, some background. Last spring/summer, the process of creating committee notes was much streamlined. A committee note can be finished by means of a simple majority vote of the committee. Public review and multi-stage processes are no longer required. (This means that the Committee Note on backwards compatibility proposed by Bill to deal with 1.0 issues is simpler, too.)


Chet suggested a way to handle machine readable artifacts using the committee notes process. We write a note “Using Standard Contracts with OBIX”. The committee note discusses standard contracts for OBIX (“Standard Contracts are like Mom and Apple Pie. You like them. Mom likes watching you consume them!” It then has a section on each set of standard contracts submitted, that references a particular artifact. All contract artifacts are kept in a particular directory under the OBIX. For example, here is the permanent repository for Energy Interop. OBIX does not yet use this format because 1.0 was from before the current process was developed.


So, for sake of discussion, say we have a contracts library. We vote, simple majority, to approve the Committee Note and the artifact gets added to the Contract Library. Sometime later, we get another submission. We talk about it, maybe tweak it, expand the committee note, and vote for a rev 2 of the Committee Note.


The contract library, then, is full of contracts. Perhaps we decide they are implemented as XSDs within the OBIX Namespace. Perhaps we annotate them with comments at the top of the artifact. Lets assume that’s what we do, and move on.


STDLIB.OBIX would them morph into obix-stdlib-201312.xsd. A new European library of Energy Contracts would morph into obix-euroenergy-201403.xsd. We can come up with some sort of artifact naming scheme that supports versioning and keep all artifacts in the contract library indefinitely. We can imagine a library bacnet-201406.xsd just as easily. Silos could arrive as medequip-201409.xsd


So that’s enough to start the conversation.






"Energy and persistence conquer all things." -- Benjamin Franklin

Toby Considine
TC9, Inc

OASIS TC Chair: oBIX & WS-Calendar

OASIS TC Editor: EMIX, Energy Interoperation

SGIP Smart Grid Architecture Committee


Email: Toby.Considine@gmail.com
Phone: (919)619-2104

blog: http://www.NewDaedalus.com



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