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

> I anticipate Tom being unhappy

Not about the non-conforming grammars bit: your previous email had convinced me.

My biggest concern is the requirement to reject non-conforming grammars:

I've been trying (with some partial success) to convince myself that a requirement for a parser to validate the input grammar isn't as big a deal for my XSLT parser as I initially thought; the process has brought up some questions.

How do parsers validate grammars as conforming?  Is it enough to assert that a given (non-xml) grammar can be parsed using the ixml grammar to produce an XML document?  How do we validate xml grammars?  Do we need one or more schema to do so?

My main (perhaps selfish) concern is that it is that writing a validator in XSLT as well as a parser will vastly inflate the complexity of the task.  If we can say that successfully parsing a given grammar using the IXML grammar to an XML instance is enough, then that is good news for me: it may mean that my parser can't accept XML grammars, but at least it means I don't have to implement a validator or serialiser to be a conforming processor.

However, if we are allowing parsers to accept XML format grammars, and requiring those parsers to validate those grammars, should we also be publishing a schema for them to do so?

I took a look yesterday at what that might look like with my go-to grammatical schema (RelaxNG), and almost immediately encountered problems around controlling the value of text nodes (in Relax, an element's content can be complex (and allow mixed text nodes) or simple (and allow value patterns), but not both).  Possibly we could work around that with Schematron, or perhaps this is a good reason to tweak the marks on the IXML grammar to bypass this restriction by removing superfluous mixed text nodes (e.g. ":" or "=" symbols from rule definitions).

Tom

_________________
Tomos Hillman
eXpertML Ltd
+44 7793 242058
On 13 Jun 2021, 01:21 +0100, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>, wrote:
>
> > 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
> ********************************************
>