I would suggest a Committee Note on
compatibility and evolution as a separate, non-normative document.
That would keep the spec simpler by breaking out those potentially
complex issues.
Notes also have a public review sequence.
Thanks!
bill
--
William Cox
Email:
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax
On 12/6/13 5:21 PM, Considine, Toby wrote:
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.
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
Finance & Administration IT
University of North Carolina
Chapel Hill, NC
Email:
Toby.Considine@
unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
http://www.NewDaedalus.com
From:
[mailto:]
On Behalf Of Chet Ensign
Sent: Friday, December 06, 2013 10:55 PM
To: Gemmill, Craig
Cc:
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.
/chet
On Fri, Dec 6, 2013 at 6:26 AM,
Gemmill, Craig <>
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?
Thanks,
Craig
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
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
