RE: [obix] Can we eliminate the encodings and messages from the core (1.x) specification? (UNCLASSIFIED)

["Bogen, Chris ERDC-RDE-ITL-MS" <Chris.Bogen@erdc.dren.mil>]

Classification: UNCLASSIFIED
Caveats: FOUO

I am all in favor of getting 1.1 out sooner than later.  However, if the encoding issues can be resolved quickly (1-2 weeks) then it's worth the effort.

I'm going to review the conformance checklist today in prep for our next meeting,

chris


-----Original Message-----
From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Considine, Toby
Sent: Monday, March 25, 2013 5:10 AM
To: obix@lists.oasis-open.org
Subject: RE: [obix] Can we eliminate the encodings and messages from the core (1.x) specification?

"A system claiming conformance with OBIX must indicate which Encoding specification(s) and which Binding specification(s) it conforms to. Such a system must provide a link to the specifications used if they are other than ones prepared by the OASIS oBIX TC. "

 

________________________________

"When one door closes, another opens; but we often look so long and so regretfully upon the closed door that we do not see the one which has opened for us." 

-- Alexander Graham Bell 

________________________________

Toby Considine

Chair, OASIS oBIX TC

Editor, OASIS EMIX, Energy Interoperation Campus Services Information Technology University of North Carolina Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu <mailto:Toby.Considine@fac.unc.edu>
Phone: (919)962-9073 

http://www.oasis-open.org
http://www.NewDaedalus.com

 

From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Markus Jung
Sent: Monday, March 25, 2013 4:59 AM
To: obix@lists.oasis-open.org
Subject: Re: [obix] Can we eliminate the encodings and messages from the core (1.x) specification?

 

I agree that it would be a nice opportunity to move the bindings and encodings part out of 1.1 already.

Maybe one fast approach would be to simple move the bindings and encodings as it is now in 1.1 WD07 simple to the separate documents, without any modification.

The REST bindings document would only contain the current HTTP section. The SOAP bindings document would only contain the current SOAP section. The encodings section would only contain the existing XML and Binary sections.

So we could make a working draft version of the bindings and encodings with the current 1.1. state, which can become a TC approved working draft in a fast way.

All new modifications (CoAP binding, JSON encoding, EXI encoding), will get introduced in a following WD of the bindings and encodings documents and can be evolved seperately from the core specification.

What do you think about this approach? I think I could prepare such working draft documents for the bindings and encodings till the Telco on Thursday.

BR
Markus

Am 24.03.2013 15:23, schrieb Toby Considine:

	I just read 1.1 WD07 from start to finish and I am concerned that we are potentially introducing new opportunities for incompatibility by including the messages and encodings in 1.1.

	 

	We touched on this last week, and skated by with little discussion. As I recall, the winning argument, mostly tacit, was that we wanted 1.1 out quickly and that it was there already, so let's just do it.

	 

	Here are the downsides:

	 

	1)      We certainly can envision a 1.1 oBIX server that communicates by JSON. In this case, and only in this case, the messaging would require external references. JSON is hot this year, something else may be hot next year. Would a COAP implementation be in compliance or not?

	2)      Advanced enterprise contracts (2.0) would certainly rely on the new encodings / messages specifications. This raises the possibility of a conformant server using the 1.1 encodings (or messages) for one message, and the external/separable encodings  for the new contracts. This strikes me as unwise.

	3)      If a new server is introduced, and it implements only the core (1.x) services, is it allowed to use the new, separable encodings and / or messaging? What if it uses the new encodings but uses messaging as defined in 1.x. This could lead to more complexity that each programmer, for client or server, must plan for.

	 

	The encodings documents and the messaging comments are coming along nicely. I foresee few arguments and little discussion aside from SOAP and the formal XSDs. These specifications could well begin their first public review shortly after 1.1 PR01. OASIS process supports referencing a draft specification. Even a completed specification can be edited, following appropriate process and votes,  to update references as they are completed: we could vote out 1.1 including a references to oBIX SOAP 1.0 PR02 and then request a technical correction to reference the completed specification. I foresee little downside in decoupling now.

	 

	It may even speed the arrival of 1.1. There would be no need to keep the specifications in sync as we work. 1.1 would instantly become smaller. As soon as we publish the REST specification (which includes JSON message patterns), and the encoding specifications, a JSON implementation would be fully 1.1. conformant. I believe this is compatible with the intent of the TC members.

	 

	A benefit if this approach is that we can then incorporate, in the 2.0 spec, the latest 1.x ("core") specification without any fear of collisions.

	 

	 

	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: Toby.Considine@gmail.com <mailto:Toby.Considine@fac.unc.edu>
Phone: (919)619-2104

http://www.tcnine.com
blog: http://www.NewDaedalus.com 

	 






--
Dipl.-Ing. Markus Jung
Research Assistant
mjung@auto.tuwien.ac.at
Tel. +43 1 58801-18322
Fax +43 1 58801-18391
Institute of Computer Aided Automation
Treitlstr. 1-3/4. Stock/E183-1
Vienna University of Technology

Classification: UNCLASSIFIED
Caveats: FOUO