Re: interoperability and extensibility (was: Re: review of conformance section and conformance language)

> On 12,Jun2021, at 9:31 AM, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
> 
> ...
> 
> At the moment, I think that all of the extensions I can think of could be turned on 
> and off easily at run time, so I think that we can safely say that a conforming processor
> must not accept non-conforming grammars.  A processor which offers extensions
> will then need to offer a ’strict conformance’ switch to turn off all its extensions and
> function as a pure conforming ixml processor.  That’s not a big burden on an implementor.

I anticipate Tom being unhappy, so let me say in advance that an alternative might be
to say something like 

    Conforming processors must accept conforming grammars. A conforming 
    processor may also accept non-conforming grammars, as extensions to the
    functionality described here.  A processor which accepts non-conforming
    grammars must provide a user option to reject any non-conforming grammar.

        Note:  A processor might, for example accept grammars in other notations, 
        or accept grammars with syntactic extensions.

That’s a little more standards-speak than most of the ixml spec, but if we 
agree on the principles we want to follow we can seek less bureaucratic ways
of describing them.

For what it’s worth, I have just looked at the section in Wirth’s Pascal Report
on compliance with ISO 7185 (worth reading if you have a copy handy), and
see that he (or the ISO WG whose words he is paraphrasing) distinguishes 
several points.  The handling of non-conforming input is more subtle and more
flexible than I remembered.  A compliant processor must

(a) accept all language features defined in the spec

(b) not require the use of substitute or additional language elements in
order to achieve something defined in the spec

(c) be able to recognize violations of the spec that are not specifically
called errors, and report them to the user.  (If it doesn’t examine
everything in the program for violations, it must say so.)

(d) handle each violation specifically called an error in one of the following ways:

    . stating in its documentation that the error is not reported
    . reporting at compilation (‘program preparation’) time that the
        error is possible
    . reporting at compilation time that the error will occur
    . reporting the error during execution
  
(e) be able “to process as an error any use of an extension of of an
implementation-dependent feature”

(f) include documentation defining all implementation-defined
features, identifying errors not reported (including errors not reported
because they are handled by an extension), and describing all extensions

In particular, I had forgotten that it allowed an implementation to omit
reporting an error, as long as the implementation confessed to that
omission in its documentation.

Michael

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cmsmcq@blackmesatech.com
http://www.blackmesatech.com
********************************************

Received on Sunday, 13 June 2021 00:21:50 UTC