OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML 1.0 Conformance Test Results



> From: "Richard Tobin" <richard@cogsci.ed.ac.uk>
>
> > In looking at the sun/valid/not-sa02.xml file, I can't find any tokens that
> > that are separated _only_ by character references to whitespace.
> 
> You're right, my description was just a shorthand for a more complicated
> set of problems.  Here is the long, historical version.
> 
> There are two aspects to it: attribute value normalization, and validation
> of normalized attributes.
> 
> NORMALIZATION:
> 
> In the first edition of XML 1.0, the description of attribute
> normalization was unclear.  Were the normalization actions listed in
> section 3.3.3 meant to be alternatives, or applied in sequence?  They
> were meant to be alternatives, but this was not everyone's
> interpretation.

Aggravated by rather excessive delays on the part of W3C when
this issue was initially raised, by the way.  Something well over a
year elapsed, as I recall ... during that time nobody at W3C seems
to have answered the question, or raised issues with this test case.

> ....
> 
> Erratum 70 (http://www.w3.org/XML/xml-19980210-errata#E70) attempted to
> make this clearer, explicitly stating that character references to
> CR, LF and TAB do not get normalized to spaces.

The 2nd edition text is a bit improved, but step 3 would still be clearer if
it said "do ONE OF the following" ... "do the following" can be sequential,
and normally means that.


> VALIDATION:
> 
> Normalization is intended to turn tokenized attributes into lists of
> tokens separated by single spaces, ...
>
> In accordance with the law of cartoon amnesia, all is well if you get
> hit on the head an even number of times.

That would seem to need to be included in the XML 2e errata ...
perhaps yet another validity constraint?  :)


> The Oasis test suite is particularly confused and the output files
> for not-sa02 and sa02 do not match any of the errata.

IMO a much saner process for W3C to follow would be to make
sure that their errata are _immediately_ reflected in the conformance
test suite.  Lags between problem reports, initial resolutions, test
updates, detection of bugs in resolutions/updates (rinse, repeat, ...)
are just trouble.

- Dave