[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Advice on Artifacts and Versions
Hi Toby,Planning for future flexibility, I think that I prefer the following:"Bindings for OBIX: SOAP Bindings v1.0"
"Bindings for OBIX: REST Bindings v1.0"
The artifacts associated with this could look like:
OBIX-SOAP-v1.0-wd08
OBIX-REST-v1.0-wd06
In my opinion, the application of the bindings to OBIX v2.0 (or later) should be described in the Introduction, body, and/or abstract, but not locked into the title.I think this structure allows the Bindings documents to evolve along with OBIX, without modifying the title (other than possibly later versions of the Bindings themselves).Of course, Chet and/or Robin may have other opinions...Best regards,PaulOn Sun, Feb 17, 2013 at 7:14 PM, Toby Considine <Toby.Considine@gmail.com> wrote:
To TCADMIN
(sorry for the story first, but this needs staging)
During the last oBIX meeting, we came to a work plan for oBIX. We plan to finish 1.1, currently at WD06 and simultaneously start on v2.0. The future work will be structured differently than in the past.
1.0 included bindings for two transports for oBIX, SOAP and REST. The nascent 1.1 has another binding, referred to as the “binary” binding, for very low level devices. There are products already based on the draft work. This is one reason we plan to complete 1.1.
In 2.0, we plan to separate the bindings from the specification. There will be multiple short specifications, as in
oBIX-SOAP
oBIX-REST
oBIX-CuAP
(There will also be a separate Encodings series, but they present no different issues)
These will be separable from the core specification. V2 also has some new features, not all of which are compatible with v1. There will be explicit oBIX contracts for energy use. Higher-level WS-Calendar-based interactions will be included. There may be a new telemetry section based on the Streams work in WS-Calendar (which will align oBIX Telemetry with Energy Interop Report Streams, while expanding the telemetry beyond energy). There will be a BIM-based service classification/ontology/framework. (Or the BIM may be a separate profile – we are still discussing that.
It is likely (not prejudging the TC) that v2 will reference v1 for low-level interactions. This means that it is possible that a v1.2 could come out (for error correction, etc.) at a later time.
So, the questions are now staged.
Should a [SOAP] binding for [oBIX] be v1 or v2? I could imagine:
"Bindings for OBIX: SOAP Bindings v1.0"
"Bindings for OBIX: REST Bindings v1.0"
Or
"Bindings for OBIX v2: SOAP Bindings v1.0"
"Bindings for OBIX v2: REST Bindings v1.0"
Or because they are replacing the bindings in 1.x
"Bindings for OBIX v2: SOAP Bindings v2.0"
"Bindings for OBIX v2: REST Bindings v2.0"
I can think of a few other variations.
The artifacts associated with this could look like:
OBIX-SOAP-1.0-WD08
OBIX-REST-1.0-WD06
OBIX-2.0-SOAP-1.0-WD08
OBIX-2.0-REST-1.0-WD06
OBIX-SOAP-2.0-WD08
OBIX-REST-2.0-WD06
BTW, there will be artifacts associated with some of these specifications. For example, the SOAP specification will include normative WSDL. The BIM-based works will certainly include some BIM-related services.
Advice, please, before I make my Document Template requests….
Thanks
tc
“It is the theory that decides what can be observed." -- Albert Einstein
Toby Considine
TC9, IncOASIS 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
--
Paul Knight - Tel: +1 781-861-1013
OASIS - Advancing open standards for the information society
Document Process Analyst
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]