[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML 1.0 Conformance Test Results
- From: David Brownell <email@example.com>
- To: Richard Tobin <firstname.lastname@example.org>, email@example.com
- Date: Wed, 13 Jun 2001 10:35:14 -0700
> From: "Richard Tobin" <firstname.lastname@example.org>
> > 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.
> 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
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.
> 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.