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] Should? or Must? re: conformance

I have a well-documented history of overthinking a problem.  (And paradoxically at the same time underthinking it...)  So I can believe that assertion.


Ok it sounds to me like the best approach would be:

·         take the ‘null=”true” ‘ sections out of the lobby and any other places where we want to require that a 1.1 server support the property.

o   note some ‘null=”true” ‘ sections may remain, in cases where the behavior is truly optional.  One example may be the new history structures.

·         Add an additional non-normative section to 17 discussing compatibility issues for developing clients and servers in 1.1, who may wish to interoperate with 1.0 clients and servers.



From: Considine, Toby [mailto:Toby.Considine@unc.edu]
Sent: Friday, December 06, 2013 5:22 PM
To: Chet Ensign; Gemmill, Craig
Cc: obix@lists.oasis-open.org
Subject: RE: [obix] Should? or Must? re: conformance


I think you are over-thinking.


All 1.1 Server MUST follow the new rules.

Those new rules would be broken if NULL were allowed, because they would have no effect.

While it would be nice if a 1.1 Client would tolerate a server breaking the rules, we do not wish to require more complexity going forward.


I would not overthink the Backwards issues. The existing implementations do not interoperate except by chance. You, quite reasonably re looking at the issues in your codebase. The issues in other codebases are slightly different, and could require their own exceptions. We do not want to bake a pile of exceptions into the requirements. While Tridium has good market reasons to be backward compatible with its product base, nothing in the spec should require others to do so.


Perhaps we should add a non-normative section, perhaps at the end of the conformance section, offering “guidance” on backward compatibility, i.e., know issues someone MAY choose to work around.


I could be talked out of this position.




"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


Editor, OASIS EMIX, Energy Interoperation
Finance & Administration IT
University of North Carolina
Chapel Hill, NC


Email: Toby.Considine@ unc.edu
Phone: (919)962-9073




From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Chet Ensign
Sent: Friday, December 06, 2013 10:55 PM
To: Gemmill, Craig
Cc: obix@lists.oasis-open.org
Subject: Re: [obix] Should? or Must? re: conformance


Hi Craig, 


Just commenting for OASIS, there are no rules about how we like or expect things done beyond the simple requirement that the spec have " a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof)." 


The TAB put together guidelines to help with writing conformance clauses and you can access that at http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html .  They are revisiting and updating it now but it is still a good basis for working. 




On Fri, Dec 6, 2013 at 6:26 AM, Gemmill, Craig <craig.gemmill@tridium.com> wrote:

As I started to write the conformance language for Section 17 based on our discussion from yesterday, I talked myself into a corner on this.  I’d appreciate some input from those familiar with OASIS rules about conformance, etc. and how they like things done.


I think our desire is:

·         for 1.1 and greater, the models, encodings, and bindings sections of the Lobby are REQUIRED

·         for 1.0, they are obviously not required, as no 1.0 server would ever have them

·         a 1.1 client should be able to handle the absence of these properties when talking to a 1.0 server

·         we want to maintain the backwards compatibility


So is the way to do this:

a)      make the properties have ‘null=”true” ‘ in the schema for the contract?  Or

b)      make the properties not be null – thus indicating they are required – but include a statement in the spec that clients must be able to handle the nonexistence of the properties?


I think we’ve been following a) so far, but perhaps b) makes better sense?  Because we DON’T want to suggest that a person implementing a 1.1 server can just decide not to have the properties, that defeats the purpose of having them!  My thought would be to take the null default off of the properties, and add language to Section 5 about the new properties, saying that clients should expect to handle them not being there for backwards compatibility.  Also probably put something into 17 somewhere that clients must be able to handle nonexistence of newer properties for this reason.


Any suggestions?





Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 


Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open

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