DOMParser RFE issues

For my Verbosio project, at least initially, I'll be allowing people to 
edit XML documents via a textarea.  I plan on using DOMParser to do 
quick well-formedness checking.  However, this presents a couple of 
problems for me.

First, the expat parser loves to spew XML well-formedness errors 
directly to the JS console.  This is appropriate for a browser, but for 
a XML editor it's a pain.  The only way I find out the document isn't 
well-formed is when DOMParser.parseFromString() returns a XML document 
with a root element name of "parsererror".

Second, parsererror elements live in the null namespace.  So if there's 
a person who is nutty enough to edit a XML document with a root element 
of parsererror, I have no way of knowing that it's a real document.

Third, when I was doing my research for this, I noticed 
nsExpatDriver::HandleError() returns NS_ERROR_HTMLPARSER_STOPPARSING...
and no one checks the return value.

I'm wondering how to make expat (and my use of DOMParser) a little better.

Most of the time I just want a yea or nay on well-formedness, and if it 
isn't well-formed, I want my application to catch the details of the 
error - not have it logged to the console directly.

In addition, because I don't want to affect how mainline Mozilla code 
uses these applications (the XML well-formedness error is useful as-is 
to others), I'd wonder how to architecturally do it in a way that didn't
regress current behavior.  This may mean that for the purpose I list 
above, I may not want to use DOMParser - but instead create (and maybe 
design?) a different component.

Before I file a bug on this, I'd like feedback on the Right Thing(s) To 
Do.  If the  three issues above wouldn't be considered a valid RFE, I'd 
like to know.

Alex Vincent