I suspect that quite a few of them also specify version="2.1".

Note that a 3.0 processor should process a stylesheet specifying 2.0 or 2.1 without error, but we should still aim to correct this unless we are actually testing the backwards compatibility rules in the spec.

Query used:
   /(xsl:stylesheet|xsl:transform)/@version
   [not(normalize-space(.) = ('1.0', '2.0', '3.0'))]

I found 38 items with a version not in (1.0, 2.0, 3.0), of which 15 where in the version test-set, 4 in backwards, 4 in errors, 1 in use-when (all deliberate)

That leaves:
* 5 times 1.1 
  - bug-3102.xsl           -> changed to 2.0
  - expression-0801.xsl    -> changed to 2.0
  - expression-0802.xsl    -> changed to 2.0
  - expression-0803.xsl    -> changed to 2.0
  - axes-049.xsl           -> changed to 1.0

* 1 time 20
  - key-050.xsl            -> changed to 1.0

* 8 times 2.1
  - streamable-065.xsl     -> changed to 3.0
  - streamable-118.xsl     -> changed to 3.0
  - streamable-121.xsl     -> changed to 3.0
  - streamable-122.xsl     -> changed to 3.0
  - streamable-123.xsl     -> changed to 3.0
  - streamable-125.xsl     -> changed to 3.0
  - streamable-128.xsl     -> changed to 3.0

Next query used (1.0):
   /cat:test-set/cat:test-case
   [cat:dependencies/cat:spec/@value[contains(., 'XSLT10')]]
   /cat:test/cat:stylesheet
   /doc(@file)/(xsl:stylesheet|xsl:transform)
   /@version[normalize-space(.) != '1.0']

Resulting 1703, of which only 8 items where deliberately wrong, and the 1630 others had version 2.0.

Next query used (2.0):
   /cat:test-set/cat:test-case
   [cat:dependencies/cat:spec/@value[contains(., 'XSLT20')]]
   /cat:test/cat:stylesheet
   /doc(@file)/(xsl:stylesheet|xsl:transform)
   /@version[normalize-space(.) != '2.0']

Resulting in 111 items of which roughly half seems to be in error (1.0 where 2.0 is expected because not testing backwards compatibility or 1.0 behavior)

Next query used (3.0):
   /cat:test-set/cat:test-case
   [cat:dependencies/cat:spec/@value = 'XSLT30+']
   /cat:test/cat:stylesheet
   /doc(@file)/(xsl:stylesheet|xsl:transform)
   /@version[normalize-space(.) != '3.0']

Result is 80 items, with at least 2 of them deliberate.

I have at this moment only fixed the 14 items mentioned in the beginning that were seriously wrong (though I doubt it influences any test results). Still thinking about fixing the others and whether or not that is actually a good idea.

I am uncertain about the many 1.0 tests that have version 2.0, because they may have been changed deliberately in this way, to allow them as 2.0 tests without them behaving in XPath 1.0 compatibility mode. When run with XSLT 1.0, and if no 2.0 features are used, this should not hamper anyone using the test suite to test an XSLT 1.0 processor.

I think it does make sense to align the other tests. These are not too many.

<quote>
Next query used (1.0):
  /cat:test-set/cat:test-case
  [cat:dependencies/cat:spec/@value[contains(., 'XSLT10')]]
  /cat:test/cat:stylesheet
  /doc(@file)/(xsl:stylesheet|xsl:transform)
  /@version[normalize-space(.) != '1.0']

Resulting 1703, of which only 8 items where deliberately wrong, and the 1630
others had version 2.0.
</quote>

Surely any test that's intended to be used under 1.0 and 2.0 but not 3.0 will have a dependency that contains "XSLT10", and most such tests will say version="2.0" because they were originally written as part of the 2.0 test suite development. They should be left alone. On the other hand, if you changed the predicate to [contains(., 'XSLT10') and not(contains(., 'XSLT20')]] that would indicate a problem.

Actually I'm not sure anyone has seriously run this test suite with a 1.0 processor to check this metadata. When they do, they can take responsibility fixing it. Our primary purpose is tests for 3.0 processors, anything else is a spin-off and a bonus.

> Our primary purpose is tests for 3.0 processors

Yes, I agree. I was just trying to be complete. 

> They should be left alone. On the other hand, if you changed the predicate to 
> [contains(., 'XSLT10') and not(contains(., 'XSLT20')]] that would indicate a 
> problem.

Tried it, result: 1696 items. I would assume these have been moved from the 1.0 testsuite and have been given a version number of 2.0, but the spec-support number remained 1.0.

Since 2.0 processors may behave differently in BC mode, and because of your comment on the focus on 3.0, I will leave these tests alone (I wouldn't even know where to begin).

----------

About 3.0 tests. I made a wrong assumption: some tests have been mirrored for 3.0 and 2.0 because of differences in test results. It would be wrong for those mirrored tests to maintain two identical files with only a version difference.

If I change the query as follows, the result is only 32 tests:

    /cat:test-set/cat:test-case
    [cat:dependencies/cat:spec/@value = 'XSLT30+']
    /cat:test/cat:stylesheet
    [let $f := @file return 
    count(
       /cat:test-set/cat:test-case
       [cat:dependencies/cat:spec/@value != 'XSLT30+']
       /cat:test/cat:stylesheet[@file = $f]) =0]
    /doc(@file)/(xsl:stylesheet|xsl:transform)
    /@version[normalize-space(.) != '3.0']

I have fixed those tests. It is possible that some of these may also work for XSLT20, I didn't check extensively whether all these tests only use 3.0 features.

--------

About 2.0 tests:

> Resulting in 111 items of which roughly half seems to be in error (1.0 where
> 2.0 is expected because not testing backwards compatibility or 1.0 behavior)

I am less confident in changing these, so unless issues come up, I will leave them for now.

Was resolved > 30 days ago, closing.