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] 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
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


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