[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Can we eliminate the encodings and messages from the core (1.x) specification?
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]