W3C home > Mailing lists > Public > www-qa@w3.org > October 2002

Re: Defining "public interfaces" in specifications

From: Eric van der Vlist <vdv@dyomedea.com>
Date: 30 Oct 2002 14:55:02 +0100
To: www-qa@w3.org
Message-Id: <1035986103.31560.75.camel@ibook>

On Tue, 2002-10-29 at 18:27, David Marston/Cambridge/IBM wrote:

> 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 am not completely sold either and see the risks, but I am really
worried that all these specs will become a nightmare!

In my mind, this wouldn't be so much an intention to have backward
compatibility on the definitions themselves (definitions can change as
the behavior of a method in a public interface can change between
versions) but an intention to maintain the the interface itself.

Taking back the issue of XML 1.1 which has changed the definition of a
XML name, I think that this should still be allowed. 

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

Yes, that's what I meant saying that unique identifiers would be given
to these public interfaces. It would become much easier to evaluate the
impact of changing one them.

> 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.)

There are all kind of impacts, and if we come back to XML 1.1 and XPath
1.0, yes a XSLT processor would behave differently when it supports XML
1.1 and XPath 1.0 than when its supports XML 1.0 and XPath 1.0.

Eric

> .................David Marston
> 
> 
-- 
See you in Baltimore.
                                    http://www.xmlconference.org/xmlusa/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
Received on Wednesday, 30 October 2002 08:55:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:59 GMT