Re: Test suite results

Norm Tovey-Walsh writes:

> Norm Tovey-Walsh <norm@saxonica.com> writes:
>> [[PGP Signed Part:Undecided]]
>>> There is no mechanism in ixml to allow any grammar + input pair to
>>> produce any output outside the outermost element of the output.  So a
>>> QT-based evaluator should start its comparison with the element, not
>>> with the document node, and evaluators built with other tools should
>>> analogously ignore the leading newline you will find in many of the
>>> *.output.xml files.
>
> Mea culpa. Because the “toString()” representation of my node object
> pretty prints the output, I misdiagnosed the problem. I’d already worked
> out that content before and after the document element was out-of-scope.
>
> No, the real problem is that the test suite says the result should be:
>
> <data>
>    <range1>5</range1>
>    <range2> </range2>
> </data>
>
> when the grammar produces:
>
> <data><range1>5</range1><range2> </range2></data>

Ah.  Another flaw in my work process; explanation below.

> I’d ask if we are just supposed to ignore whitespace, but this test
> *requires* that I get the tab in the right place, so I don’t think
> that’s reasonable.
>
> Looking at other tests, I see many have been reformated so that the
> pretty printing puts whitespace in irrelevant places, but this one
> perhaps has been overlooked. I think the correct solution here is to
> reformat the expected result:
>
> <data
>   ><range1>5</range1
>   ><range2> </range2
>></data>

I agree.

What happened here is that I took the easy shortcut of running my
processor over the tests and changing the tests or the expected result
when my processor disagreed with them, and accepting the tests where my
processor agreed or showed a bug.  The range in this test leads
Aparecium in its current state to call the XPath function
codepoints-to-string(0), which of course produces an exception since 0
is not a code point for a legal XML character.

So I never got to the point of realizing that the expected output here
contains non-significant whitespace or fixing it.

> I’d like to make a pull request for that change, but we need to settle
> the question of where and how the test suite is maintained first :-(

OK.  But I'll go ahead and make that change to my local copy, and I may
end up pushing it to the repo at some point.


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Wednesday, 2 February 2022 14:47:25 UTC