That error is raised when declared-modes is implicitly or explicitly true. The default is true for xsl:package (it is set to false for the implicit package created with xsl:stylesheet/transform). From the error:

<quote>
... or if it implicitly uses the unnamed mode and the unnamed mode is undeclared
</quote>

There is a source file, so the test is called with the default unnamed mode, which is not declared, so XTSE3085 must be raised.

I therefore think this test is correct.

The error says:

It is a static error, when the effective value of the declared-modes attribute of an xsl:package element is yes, if the package contains an explicit reference to an undeclared mode, or if it implicitly uses the unnamed mode and the unnamed mode is undeclared. A mode is declared if the package contains an xsl:mode declaration for that mode, or if the mode is a public or final mode accepted from a used package. The offending reference may occur in the mode attribute of an xsl:template or xsl:apply-templates instruction, or in an [xsl:]default-mode attribute. The offending reference may be either an explicit mode name, or the token #unnamed treated as a reference to the unnamed mode. A package implicitly uses the unnamed mode if there is an xsl:template or xsl:apply-templates element with no mode attribute, and with no ancestor-or-self having an [xsl:]default-mode attribute.

Let's analyze:

It is a static error, when the effective value of the declared-modes attribute of an xsl:package element is yes [TRUE], if the package contains an explicit reference to an undeclared mode [FALSE], or if it implicitly uses the unnamed mode [FALSE: SEE [X] BELOW] and the unnamed mode is undeclared [TRUE]. [...]

[X] A package implicitly uses the unnamed mode if there is an xsl:template or xsl:apply-templates element with no mode attribute, and with no ancestor-or-self having an [xsl:]default-mode attribute.

The package does not contain an xsl:template or xsl:apply-templates instruction therefore it does not implicitly use the unnamed mode. So in my view, there is no error.

If there is an error, then it's certainly not a static error because if we follow the reasoning in comment 1 it can only be discovered at invocation time. Perhaps we could define a static error if a stylesheet has no invocable modes, named templates, or functions, but that would be a different error entirely.

The closest error I can see is: [ERR XTDE0045] It is a dynamic error if the invocation of the stylesheet specifies an initial mode (other than the unnamed mode) that does not match either the expanded QName in the name attribute of an xsl:mode declaration, or the expanded QName in the mode attribute of any template defined in the stylesheet.

But that error explicitly exempts the unnamed mode.

Perhaps a way forward on this is to extend XTDE0045 so it reads:

[ERR XTDE0045] If the invocation of the stylesheet specifies an initial mode that does not match the expanded QName in the name attribute of any non-private xsl:mode declaration, then a dynamic error occurs if either (a) the effective value of declared-modes on the top-level package is "no", or (b) the initial mode is not the unnamed mode and does not match the expanded QName in the mode attribute of any template defined in the stylesheet.

Correction, the proposed error should read:

[ERR XTDE0045] If the invocation of the stylesheet specifies an initial mode that does not match the expanded QName in the name attribute of any non-private xsl:mode declaration, then a dynamic error occurs if either (a) the effective value of declared-modes on the top-level package is "yes", or (b) the initial mode is not the unnamed mode and does not match the expanded QName in the mode attribute of any template defined in the stylesheet.

I agree. I mean, I didn't realize the XTSE3085 being a static error (I ought to know ;). And I think it is a good thing if we catch this by editorially updating the XTDE0045, because one way or another, this is an error situation (there is no invocable mode, or anything else for that matter).

Converting this to a spec bug because the discussion suggests clarification of the wording for error conditions.

Accepted the resolution in comment 3 (but if the editor can rephrase it to avoid the double negatives he should do so).

Abel will update the test case.

The changes have been applied to the spec.

*** Bug 29491 has been marked as a duplicate of this bug. ***

*** Bug 29475 has been marked as a duplicate of this bug. ***

Update: test-case fixed (was still outstanding, see comment#6).