Re: ERB votes on error handling

At 12:10 PM 5/7/97 -0700, altheim wrote:
>So am I to understand that no compliant XML processor can be used in a
>GUI XML authoring application, as it becomes non-compliant the moment it 
>continues to send a broken XML document to the display processor? Yes, I did
>read the 'in order to support correction of errors' phrase, but it 
>seems to be contradicted in the second paragraph. If the XML editor is
>a GUI editor, 'character data extracted from markup' is what the user 
>sees, and this display is halted upon encountering the first error. And the 
>authoring application's best understanding of the document structure will
>be broken but serve as the user's clue to fixing it. Display of this is 
>also disallowed? Since I can't believe that the ERB has actually voted
>this way (hence my understanding must be flawed), could you please clarify?

The following is nothing new beyond what I've been saying in the past few
days, and I don't know if everyone on the ERB call bought my argument, but
it gives me every security that the apparent "editor hole" is not a problem.

I would say that it's certainly possible to use an XML processor *inside*
an XML-generating editor, in a "validation phase."  When you want to check
your work you do a "validate"; when the XML processor is invoked, its
normal output is dumped on the floor (but your original text is still in
the buffer or whatever), and the error messages are captured, highlighted,
and maybe even linked back to the editor display so you can fix them.  But
the usual read-write editorial functions themselves are not a good
candidate for being a *true* or *full* XML processor, since some functions
of an XML processor, including expanding internal entities and tokenizing
some attribute values, must be suppressed (or undone every time they're done).

The primary responsibility of an XML-generating application is to generate
conforming XML documents; how it achieves this may or may not use an XML
processor in the process.  For example, I doubt the average SGML-producing
perl script always runs SP over the result.  Also, I don't believe there's
a single SGML-aware editor that claims to be a "conforming SGML
application".  (Certainly ADEPT doesn't do so; it just claims to produce
conforming SGML documents, which is still a pretty strong claim.)  So I
don't think this sets any kind of dangerous precedent.

	Eve

Received on Wednesday, 7 May 1997 18:24:02 UTC