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

The other day, I noted that I was leaning towards the tight end of the conformance 
spectrum.

> On 9,Jun2021, at 11:40 AM, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
> ...
> 
> When a conforming processor is presented with a non-conforming grammar, we can either require it to report an error, or specify that its behavior in that situation is undefined, meaning implementations are not required to detect or report errors in the grammar.  Or we can require certain kinds of error recovery (as in XSLT 1.0 and de facto in some versions of HTML), and take one or the other view (fail, undefined) if those error recovery steps don't work.
> 
> Specifying that behavior is undefined is a short road to incompatible implementations, as I think can be observed in the SQL space and in Web browsers.  Requiring that errors in the input be reported is a good way of helping users learn the rules, and a good way of improving interoperability.
> 

This morning I found what I think is a well formulated argument for the other side:
Jan Wielemaker explaining why SWI Prolog does not and will not conform completely 
to the ISO Prolog standard:

https://www.swi-prolog.org/Directions.txt

Among other things, this paragraph seems relevant to me:

> The ISO standard has done a great job in synchronising and cleaning the syntax and core semantics of the language. However, the standardised core is too small to accommodate real applications, the process to enlarge is too slow (while some vendors do not even want to enlarge it) and there are no mechanisms that allow us to make even tiny incompatible changes needed to accommodate new features in a clean way. Especially this last restriction turns it into a practically dead language.

I don’t think JW’s arguments have changed my mind with respect to ixml — ixml is not
a programming language in the same sense, and the living/dead language distinction does
not seem to apply in quite the same way — but they do seem to identify one danger of
being too restrictive.  And they help explain why the SQL spec does not require conforming
processors to reject non-standard syntax or other extensions.

With respect to ixml, it seems clear that the core functionality provided in the existing
spec is useful as it stands, and it also seems clear that there are several ways in which 
it might be extended, as well as some people who are inclined to extend it in that way:

  - being able to produce namespaced XML

  - being able to use ixml to transform into a wider range of XML outputs, so as
to eliminate some cases which now require post-processing with XSLT or some other
processor

  - being able to use ixml grammars to specify two-way mappings in a larger range 
of cases

  - being able to use a single processor to accept grammars both in ixml syntax and
in other well known grammar formalisms, e.g. IETF’s ABNF or ISO EBNF or the
input format of REX, or ...

  - being able to use ixml to represent arbitrary finite state automata for a set of
FSA tools

  - being able to use ixml to represent attribute gramars or affix grammars

We can say “these are all fine things but they are out of scope for ixml, good luck to 
you on your journey”.  If we do, we can expect that people who want to do these things 
will develop something similar to ixml (and competing with ixml in ixml’s core space)
but named differently and inevitably competing for users and implementors and
mind share with ixml.  

Or we can try to make sure that whoever wants to do these things will build on 
ixml in a compatible way, and that useful functionality developed in this way can be
integrated into some future ixml spec.

I think it is the case that if text-to-XML processors which support these features
are developed, I would rather that they be extensions to ixml than that they be
competitors to ixml.  I think that means we should try to have some extensibility
story to tell.  That’s one reason I would like a syntax for pragmas, but we may need
more in the story, for cases where pragmas are just too clumsy.

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.

If we expect that there might be extensions which would make that difficult, so
the implementor must choose between offering the extension and claiming conformance,
then I think there would be a case for a different conformance story.  

As I think about this, however, I am acutely aware that until we have multiple publicly
available implementations of ixml, all of these questions about the conformance clause
feel like purely theoretical problems.  I would like to challenge everyone who is now
working on an ixml implementation to move it forward a little faster, and if we can
find ways to organize our calls to encourage that, that would be a good way to
use the calls.

Michael


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

Received on Saturday, 12 June 2021 15:32:18 UTC