W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > August 2008

Re: problem with XML W3C Conformance Test Suite 20080205

From: Daniel Veillard <veillard@redhat.com>
Date: Fri, 8 Aug 2008 11:38:34 -0400
To: Richard Tobin <richard@inf.ed.ac.uk>
Cc: public-xml-testsuite@w3.org, public-xml-core-wg@w3.org
Message-ID: <20080808153834.GC24385@redhat.com>

On Thu, Aug 07, 2008 at 05:36:57PM +0100, Richard Tobin wrote:
> >   To me a plain well-formedness error clearly take precedence over a
> > namespace error since document which doesn't conform to REC-xml-names can
> > still be usable data, while a not well-formed one must break. 
> >   I still think the error is miscategorized, and will supress it from 
> > my regression runs. And I really don't think XML parsers should report
> > a namespace error there but the XML-1.0 wellformedness error which is
> > far more critical and general.
> The test suite doesn't require any particular error message.  To
> pass the test all you have to do is reject the document.  The fact
> that you reject it because of the XML well-formedness error is
> unimportant.

  I disgree again.

  (or the example used in the test)

is a well formed document. It has no way to indicate it expect (or not) to
use namespace, a XML-1.0 parser must accept it. Now a NS-1.0 compliant parser
must report the violation, but nowhere from section 7 or 8 is the parser
instructed to *reject* the document.
Hence it's my opinion important that XML parser do not reject document
not namespace-well-formed , but as indicated they must report the error
if they want to be NS-1.0 compliant.

Assuming rejection for NS-1.0 compliance sounds wrong to me. This case
of the test suite seems to assume this.


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/
Received on Friday, 8 August 2008 15:39:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:39 UTC