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.
Bests,
Markus
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.
http://docs.oasis-open.org/energyinterop/ei/v1.0/
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.
Discuss…
tc
"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:
Phone: (919)619-2104
http://www.tcnine.com
blog: http://www.NewDaedalus.com
