[XML-SIG] Big Bug? (was:Pretty-printing DOM trees)

[Sean Mc Grath]

[Greg Stein]
>
>Push back against where the file came from. What if somebody sent you a
>bad executable? Do you try to correct it? What if they send a bad MSFT
>Word file? Do you try to correct it? Makefiles with spaces instead of
>tabs? crontab files with a missing column? etc. etc.
>
>Well, the same for XML. If it is bad, then you ask for a correct one. Why
>should XML be any different than the multitude of documents that you deal
>with every day?
>

Some "document" types such as C++ source code for example
benefit, in my opinion, from error recovery parsing. Nobody
wants a C++ compiler to generate executable code in the face of
errors but getting a listing of more than one error
increases your chances of fixing more than one error
in a single edit-compile cycle.

I belive an analogy with XML here is valid.
In production use, it makes total sense for an XML parser
to stop stone dead on error. For development use,
an XL parser that can recover from certain types
of error is a darned useful thing.

To give a concrete example, an XML parser with
optional error recovery would be wonderful for
XML up-translation work. There are many occasions
when you have automated the creation of pseudo-XML
and you want to cut code to get it the rest of the
way to full XML. Stop dead parsers are useless for
this type of work.

So, I would like to see xmlproc having
some optional error recovery functionality
that I could turn on for up-translation
parsing.

I realize that this is a contentious opinion:-)


<Sean uri="http://www.digitome.com/sean.htm"/>