Some prior art re diagnostics detection and handling

[Francis Cave]

Dear all

As a result of today's meeting I have tried to record the consensus reached
in changed to the wiki text.

I started by tidying up text already marked for deletion by Murata-san.

In X.1 I added a Note about what happens when an MCE processor detects that
the document does not conform to the syntactic constraints of Clause X. No
particular behaviour is required, but I believe that we should recommend
that the MCE processor signals the non-conformance, as this seems consistent
with the intent of the current text and is supported by the examples
provided by Murata-san (XML), Rex (C) and Caroline (XSLT).

I have changed "reported" to "signalled" throughout.

In Y.1 I have added a final sentence to the first paragraph making it clear
that the MCE processor is required to signal mismatches, but may continue
normal MCE processing.

In Y.4 (Step 3) I have made some minor editorial corrections to 5-7, and
have added 8, so that this step also includes what happens when a
non-ignorable foreign child element is encountered within AlternateContent.
The more I think about this, the more I'm convinced that this is simply a
third kind of mismatch. The signalled mismatch type is a bit verbose - any
suggestions for improvement?

Regards,

Francis




> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA
> Makoto
> Sent: 16 November 2012 22:29
> To: SC 34 WG4
> Subject: Re: Some prior art re diagnostics detection and handling
> 
> Here is what XML (fifth edition) says.
> 
> error
> [Definition: A violation of the rules of this specification; results
> are undefined.
> Unless otherwise specified, failure to observe a prescription of this
> specification
> indicated by one of the keywords must, required, must not, shall and
> shall not
> is an error. Conforming software may detect and report an error and
> may recover from it.]
> 
> fatal error
> [Definition: An error which a conforming XML processor must detect
> and report to the application. After encountering a fatal error, the
> processor
> may continue processing the data to search for further errors and may
> report such errors to the application. In order to support correction
> of errors, the processor may make unprocessed data from the document
> (with intermingled character data and markup) available to the
> application.
> Once a fatal error is detected, however, the processor must not
> continue
> normal processing (i.e., it must not continue to pass character data
> and
> information about the document's logical structure to the application
> in
> the normal way).]
> 
> Regards,
> Makoto
> 
> 2012/11/17 Rex Jaeschke <rex at rexjaeschke.com>:
> > As discussed on the telcon today:
> >
> >
> >
> >
> >
> > From 9899:2011 (C Language Standard)
> >
> >
> >
> > 5.1.1.3 Diagnostics
> >
> > 1 A conforming implementation shall produce at least one diagnostic
> message
> > (identified in
> >
> > an implementation-defined manner) if a preprocessing translation unit
> or
> > translation unit
> >
> > contains a violation of any syntax rule or constraint, even if the
> behavior
> > is also explicitly
> >
> > specified as undefined or implementation-defined. Diagnostic messages
> need
> > not be
> >
> > produced in other circumstances. Footnote 9)
> >
> >
> >
> > Footnote 9) The intent is that an implementation should identify the
> nature
> > of, and where possible localize, each
> >
> > violation. Of course, an implementation is free to produce any number
> of
> > diagnostics as long as a
> >
> > valid program is still correctly translated. It may also successfully
> > translate an invalid program.
> >
> >
> >
> > Rex
> >
> >
> 
> 
> 
> --
> 
> Praying for the victims of the Japan Tohoku earthquake
> 
> Makoto