Re: Defining "public interfaces" in specifications

Jumping into the debate between Eric van der Vlist and Thomas B. Passin:

TBP>>Including  specs by reference is good, but including the "current
TBP>>version" by reference is onerous and even dangerous.  Should the
TBP>>referenced spec get changed, entirely out of your control, your
TBP>>product is suddenly non-conforming.  It would be impossible to know
TBP>>what really is supported or how a processor should work, since it
TBP>>might or might not have been brought up to the new standard.

EvdV>That's because the specs do not provide "public interfaces" which
EvdV>they are commited to maintain over versions or explicitely
EvdV>deprecate. If each specification had to supply a list of
EvdV>definitions which will be maintained over versions or slowly
EvdV>deprecated, other specs would know what they can safely refer to
EvdV>and could afford to rely on the latest release.

I'm still not completely sold on it, but I like the notion that the
WG takes some formal step to state that they intend to have backward
compatibility. I would like to re-introduce an additional notion, that
the W3C QA Team keeps a "registry" where spec dependencies must be
registered. This will aid future work, because concern about support
or deprecation will be focused only on those versions that have a
registered dependency from some other spec.

Example: the XBlah WG decides they need to deprecate a certain item
when 4.0 comes out. The registry tells them that other specs have
normatively referenced versions 2.1 and 3.0, but not 1.0, 2.0, 3.1,
nor 3.2. If Eric's plan is in effect, implementations of other specs
that depend on XBlah 3.0 may have incorporated 3.1 or 3.2 features,
but the spec being implemented only depends on XBlah 3.0. The XBlah
WG defines the deprecation in 4.0 with particular attention to
non-catastrophic breakage against 3.0 and 2.1.

As TBP recognizes, there will be issues of applying a conformance
test suite. In some cases, it may be possible to bundle the tests
where differences are significant and then include/exclude them
using mechanisms that will apply to discretionary items. One tactic
that would help is if the WG makes an irrevocable commitment that
certain element/attribute/function/keyword strings will always be
invalid, so there can be error tests that are upward compatible.
(Example, if XPath will *never* include a junk() function, then I
can write my negative tests for invalid function name and my
positive test for function-available() returning false, assured
that the tests will behave the same way in future versions, by
using that name.)
.................David Marston

Received on Tuesday, 29 October 2002 12:35:24 UTC