Looking deeper into this, we say in 3.13.2 that after XPath evaluation: "The value V is the result of evaluating the value template.".

V is defined as the attribute value in the source XDM. That XDM may or may not be typed, so either a type error may occur, or, if it isn't typed, an error occurs when the pre-compiled stylesheet is henceforth processed.

I think that in both cases (either via validation or via parsing) the resulting value with whitespace should cause an error, though this is not immediately obvious.

As an aside, it seems reasonable to relax this a little. For instance, we could change the line above to something like:

"The value V is the result of evaluating the value template cast to the typed value of the attribute as defined by this specification.".

But while this seems reasonable and would solve some problems, it opens up others: there's no way to cast an EQName to a QName and possibly there are other caveats.

Another alternative is to explicitly say that leading/trailing whitespace is stipped (if that's the behavior we are after).

If we leave it as is, perhaps we can emphasize this by adding a Note, something along these lines:

"Note: the result of evaluating a value template is a string value. This string value becomes the effective value of the (untyped) attribute and must match any production rules of that value as defined in this specification. This has the effect that leading spaces in the resulting string value are not collapsed as they are for a literal attribute in an XML document instance of a stylesheet. As an example, consider... [add example]"

Section 5.6 says 

[Definition: The result of evaluating a value template is referred to as its effective value.] The effective value is the string obtained by concatenating the expansions of the fixed and variable parts:

So I'm really not sure what comment #1 is about.

Regarding comment #0, section 2.2 says:

Except where the set of allowed values of an attribute is specified using the italicized name string or char, leading and trailing whitespace in the attribute value is ignored. In the case of an attribute value template, this applies to the effective value obtained when the attribute value template is expanded.

This seems to make it quite clear in my mind that the two examples in comment #0 are both legal.

You quoted this part:

> In the case of an attribute value template, this applies to the effective 
> value obtained when the attribute value template is expanded.

and then you came to this conclusion:

> This seems to make it quite clear in my mind that the two examples in 
> comment#0 are both legal.

But I read this exactly opposite: "this applies to the effective value ... AVT is expanded".

That suggests to me that the result of the expression is what is valid and the whitespace rule from the previous sentence apparently does *not* apply. At least that's how I understand it.

But maybe we misunderstand each other? The expression itself is legal, but after the expression is evaluated, the *effective value* is a value with leading/trailing spaces, which are retained, but lead to an error because the value of the attribute is not allowed to have a space in the name.

Note that my current version of both Exselt and Saxon interpret it this way (that is, the code in comment#0 leads to an error: invalid QName), but my Saxon version needs updating, I'm not sure it is still that way.

The point of raising this is that I think the text is open to interpretations and I am still not convinced we say anywhere that the resulting value of a *static* AVT is stripped of whitespace. In fact, both your quotes and the text I found suggest otherwise (to me, at least).

My reading of:

leading and trailing whitespace in the attribute value is ignored. In the case of an attribute value template, this applies to the effective value obtained when the attribute value template is expanded.

is

"leading and trailing whitespace in the effective value of the AVT is ignored", which in turn means "the rules for validity of the value apply after leading and trailing whitespace has been stripped".

I'm having trouble seeing how it can be read any other way (but perhaps I've read it too often...)

The way I see this: the good news is that at least the intention of the spec is that whitespace should be ignored. So, the unlucky difference between (for instance) xs:QName and fn:QName should not arise, and the example I gave should have its whitespace stripped and raise no invalid-attribute-value error (after static expr. expansion).

But let me try to explain how I read that line by how my thought-process went:

"leading and trailing whitespace in the attribute value is ignored."

I thought: OK, so given an attribute in an XDM the l/t whitespace is ignored.

"In the case of an attribute value template"

I thought: Aha, we introduce a special case, so something is different.

"this applies to the effective value obtained when the attribute value template is expanded."

I thought: this (whether or not ws is removed) is the value used by obtaining it by expanding the AVT.

But if I ignore my feeling that an exception was introduced, it becomes hard to see "this" referring to anything but the previous rule. But I really didn't see it on multiple reads of the prose.

------------

I'm sorry for the lengthy discussion that appears to boil down to a single word that I took for referring to the wrong subject.

So, perhaps this would be a potential clearer sentence?

<proposal>
"Leading and trailing whitespace in the attribute value or *effective value* of an *attribute value template* are ignored, except where the set of allowed values of an attribute is specified using the italicized name string or char."
</proposal>


(shouldn't s/is/are/, because of "leading *and* trailing"?)