I agree that the assert-string-value is incorrect and since the XML document containing the test is XML 1.0 it cannot be made correct. 

I think the test should probably be split in two: 

1) one with an XML 1.1 dependency with an XPath test like string-to-codepoints(.) = 8, or a serialization-matches test.

2) and one without the XML 1.1 dependency testing for FOCH0001.

Possibly the test typically succeeds most of the time because XML 1.0 is used with processors unless the dependency is set in the test. In such cases the FOCH0001 should always throw.

>2) and one without the XML 1.1 dependency testing for FOCH0001.

And with an XML 1.0 dependency

> And with an XML 1.0 dependency
Such dependency does not exist, it is a minimum requirement to support XML 1.0.

There is one:

<dependency type="xml-version" value="1.0"/>

(In reply to Benito van der Zander from comment #4)
> There is one:
> 
> <dependency type="xml-version" value="1.0"/>
Interesting. I just did a search and it is used 40x. Funny, never noticed it before. Looking at those tests I see how it is supposed to have meaning (i.e., should run on 1.0, not 1.1), though the more logical choice imho would be:

<dependency type="xml-version" value="1.1" satisfies="false"/>

Tx for pointing that out and sorry for the clutter...

I have split the tests according to comment #1.

Would there be an objection to testing the result without using seialization-matches, as this test isn't really about serialization?

For historical reasons, in our test harness we compare using canonical XML (as per the old XQTS), which happens not to escape this character.

I fear if we change our test harness, we may end up having to file bug after bug about whitespace.

Yes it's always good practice to avoid using serialization-matches assertions except when you're actually testing serialization.

Changed the expected result to

<assert>string-to-codepoints($result) eq 8</assert>

Now updated.

I still see:

   <test-case name="K-CodepointToStringFunc-8a">
       ...
       <assert-string-value>&#8;</assert-string-value>

I am changing it to:

       <assert>string-to-codepoints($result) eq 8</assert>

Currently I am unable to parse the catalog file with my 1.0 parser.

(In reply to Josh Spiegel from comment #11)
> Currently I am unable to parse the catalog file with my 1.0 parser.

Sorry Josh - thanks for fixing it.