Note: this is the interpretation assumed by the expected results for test package-912.

In section 3.5.6 it says:

   « The global context item is available only within the top-level package. If
   a valid xsl:global-context-item declaration appears within a library 
   package, then it is ignored, unless it specifies use="required", in which 
   case an error is signaled: [see ERR XTTE0590].»

I think that answers the question you're asking, but it would probably be better to either repeat this statement, or to link to it from 5.3.3.1.

Note that this doesn't forbid creating an abstract variable that can be overridden with a new variable that accesses the global context item.

All in all, I think these rules make sense:

* If a library package could access the global context item, it should be able to declare that wish

* But one library package with <xsl:global-context-item use="required" /> and one with <xsl:global-context-item use="prohibited" /> creates an unresolvable conflict. 

So:

* global xsl:variable etc that can access the context item can only do so if that package becomes the top level package

* the xsl:global-context-item declaration can be used in a library, but will be ignored (I think it would have been better if it would always raise an error).

In light of this, I think this is confusion in the same section:

    « A type error is signaled if there is a package with an xsl:global-context-
    item declaration specifying a required type that does not match the supplied 
    global context item. The error code is the same as for xsl:param: [see ERR 
    XTTE0590].»

We should replace "a package" with "a top level package" (the global context item declaration is said to be ignored otherwise, and this statement seems to contradict that).

I have drafted erratum E7.

To be honest, I don't think many people would be confused by the text as currently written, because most people think of the global variables in a package as being the variables declared in that package, not those that are injected into the package as a result of a use-package declaration. So in the draft I've tried to avoid confusing the reader unnecessarily with these complications.

I read Abel's comment #2 several times and eventually realised that it points out another quite separate problem: in 3.5.6 there is a contradiction between the two (essentially consecutive) paragraphs, where the first says

(1) If a valid xsl:global-context-item declaration appears within a library package, then it is ignored,

and the second says

(2) A type error is signaled if there is a package with an xsl:global-context-item declaration specifying a required type that does not match the supplied global context item.

On balance I agree with Abel that (1) makes more sense, and we should therefore change (2) to read

(2a) A type error is signaled if the top-level package has an xsl:global-context-item declaration that specifies a required type that does not match the supplied global context item.

I will factor this in to the proposed erratum.

The proposed erratum has been revised to incorporate the change proposed:
(2) changes to (2a) as described in comment #2.

I agree. Now we have a clean situation where:

a) Any xsl:global-context-item declaration in a library package is ignored (its use-attribute has no effect whatsoever)

b) The xsl:global-context-item declaration in the top-level package has only effect on that top-level package and cannot be referenced directly from a library package (using "." in a global variable in a library package is an error).

That means that, if a library package needs to access the global context item from within global variables, it can do so as follows:

## library package:

<xsl:variable name="vat-glob" visibility="abstract" />
<xsl:variable name="vat" select="$vat-glob" />

## top-level package:

<xsl:override>
   <xsl:variable name="vat-glob" select="./tax/@vat" visibility="public" />
</xsl:variable>

Note: I didn't realize this before, but this specific situation is explained in a Note under https://www.w3.org/TR/xslt-30/#dt-initial-named-template, namely this part:

  « When a stylesheet parameter is defined in a library package, it is possible
  for a using package to supply a value for the parameter by overriding the
  parameter declaration within an xsl:override element. If the using package is
  the top-level package then the overriding declaration can refer to the global
  context item. »

I wouldn't object to a little example (like above) to be added to the erratum, if you think that's feasible. The reason being that this is a rather complex situation and an example would better illustrate other readers why we are fine-tuning this errors.

## About the proposed changes

We changed "global variables in the top-level package" to "global variables declared in the top-level package".

I agree that this removes the ambiguity from referenced variables, but it adds an ambiguity on overridden variables: they can be *declared* in a library package, but *overridden* in the top-level package.

Could you consider changing "declared in" to "declared or overridden in"? I think that's better.

You marked this change *substantive*. I think it isn't, as there is no change in behavior, in particular the referenced NOTE above shows that the intent of the specification has always been like we currently more diligently describe it to be. Suggestion: change it to *editorial*?

(In reply to Abel Braaksma from comment #5)
> a) Any xsl:global-context-item declaration in a library package is ignored
> (its use-attribute has no effect whatsoever)
Sorry, this part isn't correct. When use="required" it raises XTTE0590 (if in a library package). All other cases, it is ignored. Why did we create this exception-to-the-rule? I have no idea. 

> if a library package needs to access the global context item from within 
> global variables, it can do so as follows:
I wonder if this is valid:


## library package:

<xsl:variable name="vat-glob" select="./foo" visibility="public" />

## top-level package:

<xsl:override>
   <xsl:variable name="vat-glob" select="./tax/@vat" visibility="public" />
</xsl:variable>

I *think* we raise an error here only if the library package is not overridden in the top-level package. If so, this would be another way to write this, *and* it allows for better reusability for library packages that can also be used as top-level package.

This illustrates again why it may be wise to add an example to erratum E7.