Re: XML 1.0 Conformance Test Results

[Rob Lugt <roblugt@elcel.com>]

Hi Richard, please see the comments in-line.

>
> >Canonical output mismatch between sun/valid/not-sa02.xml and
> >sun/valid/out/not-sa02.xml
>
> and
>
> >Canonical output mismatch between sun/valid/sa02.xml and
> >sun/valid/out/sa02.xml
>
> There has been some confusion about the validity of tokens separated
> by character references to whitespace (which depends on the
> definitions of Names and Nmtokens).  They were outlawed by first
> edition erratum 62, which was reversed by erratum 108 (apparently
> because of a misunderstanding) and have been outlawed again by second
> editions erratum 20.  The end result is that there examples are not
> valid and should therefore not have any canonical output!
>

Thanks for pointing that out.  We'll address it in the next release of the
Validator.

>
> Here are some more problems:
>
> CR characters incorrectly inserted in:
>  xmltest/valid/sa/out/098.xml
>  sun/valid/out/{not-sa0[1234].xml,notation01.xml,sa0[2345].xml}
>
> (actually there are CRs in all the files, probably because the test
> suite passed through MS Windows; these are the ones where it makes a
> difference).

These CRs are removed by the patch [1] - but I agree the test files need
fixing.

>
> ibm-invalid-P29-ibm29i01.xml
> ibm-valid-P28-ibm28v02.xml
> ibm-valid-P29-ibm29v0[12].xml
> output file has PI before the DTD (wrong per the Sun canonical form
> definition)

The only definition for the Sun canonical form that I have found is the one
packaged with the conformance tests.  This is labelled "Draft 1" and does,
as you state, indicate that the DTD should appear first.   The link to the
online document is broken.  I wonder if all current implementations
currently emit PIs in the order (relative to the DTD) that they appear (as
ours does).

> valid-sa-094 well-formed because PEs are not expanded in attvalue

Agreed.  I forgot that we updated our local test file to change this, but I
have already written to the OASIS Conformance TC about it.

> ibm-not-wf-P77-ibm77n03.xml
> ibm-not-wf-P77-ibm77n04.xml
> don't test what they're meant to because the encoding is "UTF8" instead of
> "UTF-8".

Interesting.  We have followed the convention that other processors seem to
have adopted of treating UTF8 as an alias for UTF-8.  Just like ASCII is
treated as an alias for US-ASCII.  Do you think this is wrong?

Regards
Rob Lugt
ElCel Technology

[1] http://xmlconf.sourceforge.net/xml/update.sh
[2] http://www.jclark.com/xml/canonxml.html