Re: Defining "public interfaces" in specifications

On Sun, 2002-10-27 at 18:36, Alex Rousskov wrote:
> On 27 Oct 2002, Eric van der Vlist wrote:
> 
> > That's because the specs do not provide "public interfaces" which
> > they are commited to maintain over versions or explicitely
> > deprecate. If each specification had to supply a list of definitions
> > which will be maintained over versions or slowly deprecated, other
> > specs would know what they can safely refer to and could afford to
> > rely on the latest release.
> 
> The spec itself is such a public interface. 

Not quite, or at least not every snippet of a spec as the same ability
of being used as a reference (or public interface).

Let's take some examples from XML 1.0.

"[Definition: A Name is a token beginning with a letter or one of a few
punctuation characters, and continuing with letters, digits, hyphens,
underscores, colons, or full stops, together known as name characters.]"

This one, explicitely marked as a "Definition" is obviously something on
which other specs may rely. But these "interfaces" are not always marked
as such and the following sentence:

"Names beginning with the string "xml", or any string which would match
(('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in
this or future versions of this specification."

is obviously in the same category.

These statements could be formally identified as "XML Name definition"
and "XML reserved names". 

On the other extrimity, a sentence such as:

"In editing XML documents, it is often convenient to use "white space"
(spaces, tabs, and blank lines) to set apart the markup for greater
readability."

is obviously something which other specs will rely on.

Between these two opposite cases, there are grey areas for which it's
more fuzzy to know if they are things you can rely on or not.

The fact to identify the sections on which one can rely (and giving them
identifiers) would IMO facilitate the work of people refering to the
specs and also the tracking of interdependences between specs.

> It is an implied
> assumption behind virtually every spec that future versions of the
> spec will be "backword compatible" if it makes sense to support such
> compatibility or "explicitely deprecated" if it does not.

I don't think so either. When a spec is completely rewriten and
restructured (like between XPath 1.0 and XPath 2.0), there is no
assumption that the definitions found in the both versions will be easy
to match.

If the definitions were formally identified, this match would be trivial
to perform.

> 
> > That was the situation with libraries before we used to define
> > publics interfaces. The current situation isn't perfect, moving
> > between different versions of libraries isn't tatally seamless but
> > IMO that's much better and a step forward.
> 
> The current situation with libraries is pretty much equivalent to the
> current situation with specs. A public interface of a library is
> simply implementation of a [usually public] spec.
> 
> > >
> > > In practically all US government specs, you will see other documents
> > > included by reference, by always qualified by the phrase "of the exact issue
> > > specified".  That is how it should be.
> >
> > But this is creating specs which are modular only by name and
> > cascading updates such as we have now with XML 1.1 which requires to
> > update 80% of the W3C X* specs to become effective.
> 
> I probably do not understand your notion of "modularity". What you
> propose does not improve modularity (as I understand that term)
> compared to the current best practice. It just makes it
> administratively more difficult to change certain specs, that's all.

What I mean is that when you develop a lot of "small" specs like the W3C
XML related specs, they become a nightmare to maintain if you need to
publish new editions of the whole collection each time one of them is
edited and that seems to become the case with the example of XML 1.1.

My proposal tend to replace the need for publishing new editions with
the need of eventually doing certifications of specs. In this case,
XPath 1.0 would need to be "certified" with XML 1.1 to check that
nothing is broken which is different from needing a new edition.

> IMO, it should be up to spec authors whether to retain backward
> compatibility or not. If another spec is cited, it should be named
> exactly, including its version number if applicable (which, BTW, is
> still not 100% precise because of the errata issues).

Then it's not to the spec authors to decide since you impose to accept
no compatibility a priori :-) !

> If a spec is introducing a concept that does not really belong to that
> spec because it has a much broader scope, the authors should consider
> extracting that concept into its own [smaller] spec. Similarly, if a
> needed concept is found in another spec, it can be put into its own
> spec if desired. I think such extraction and factorization events has
> happened several times with URLs and other basic Web objects.
> 
> > as we have now with XML 1.1 which requires to update 80% of the W3C
> > X* specs to become effective.
> 
> If XML 1.1 is backward compatible with XML 1.0, there should be no
> reason to update 80% of X* specs. If it is not backward compatible, a
> careful rewrite would be required anyway. Note that "backward
> compatible" status may depend on a particular context/way in which an
> X* spec is using XML 1.0.

XML 1.1 is not backward compatible with XML 1.0. but a rewriting of
XPath 1.0 (to keep this exampe) isn't necessary since the new definition
of a "XML name" is compatible (AFAIK) with the syntax of XPath.

Thanks,

Eric
> 
> Alex.
> 
> -- 
>                             | HTTP performance - Web Polygraph benchmark
> www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>                             | all of the above - PolyBox appliance
> 
> 
-- 
Rendez-vous a Paris (Forum XML).
                          http://www.technoforum.fr/integ2002/index.html
------------------------------------------------------------------------
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:24:29 UTC