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

[Christian Tismer]

Greg Stein wrote:
> 
> Christian Tismer wrote:
...
> > Aaahh, oh, whow, thanks.
> > Maybe xmlproc should be a little more forgiving for this case
> > and not skip beyond ">" but just skip (or repair) the attribute.
> 
> It should *NOT* repair the attribute. That will simply encourage poor
> XML authoring. It should report the error properly (or, alternatively,
> the error should be responded to properly).

Well, I agree. It should not encourage bad authoring.
But I, as a complete newbie to a SIG which is very evolving,
was kind of struggling with a lot of code, many parsers, and so
on. I think, others will get into at least as much trouble
as I had.
Furthermore, the file which I wanted to inspect wasn't mine.
What should I do if I'm confronted with foreign XML files
which have some flaws, and the parser doesn't make it through
it. The argument is fine for me, but in this case I have
no chance.
For my custom work, it would be best to have a parser which
*does* complain about an error, but also repairs easy cases
like this. This gives me a chance to work with the file,
inspect it and complain to my customer.
This is easy after all since I now know enough of
the XML package and can help myself.

The remaining qeustion is: How should faulty XML be handled
at all? There are enough examples where you cannot simply
reject the document. You need to read it.
Does it make sense to think of a "correcting"
parser which turns a bad document into something well-formed
which can be inspected with an XML browser, together with
some error-annotation tags?

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.skyport.net
10553 Berlin                 :     PGP key -> http://pgp.ai.mit.edu/
     we're tired of banana software - shipped green, ripens at home