Mike,
The purpose of a Schema Element Test is to measure whether a given element 
satisfies the schema element declaration of the same name. If the schema 
element declaration specifies "nillable", the element may satisfy this 
declaration by having a "nilled" property that is either "true" or "false". If 
the schema element declaration specifies "not nillable", the element must 
have "nilled" = "false". In other words, the only way in which a "nilled" 
property could cause an element to fail to satisfy its element declaration is 
if the declaration specifies "not nillable" but the element has "nilled" 
= "true". This corresponds exactly to the specification in XQuery Section 
2.5.4.4.

Please let me know whether this explanation resolves your issue.
Thanks,
Don Chamberlin

You say: the only way in which a "nilled" property could cause an element to
fail to satisfy its element declaration is if the declaration specifies "not
nillable" but the element has "nilled" = "true".

I was under the impression that such an element could not exist. But I see now
that it can: if there's a global element declaration E(1) specifying
nillable="no", and a local element declaration E(2) specifying nillable="yes",
and if our particular element node specifies xsi:nil="true" and was validated
against E(2).

So it seems that the current rule is in fact logical. I'm not sure it's a good
rule - I would prefer nilled elements not to satisfy the schema-element(E)
SequenceType. (Actually, I would prefer nilled elements to disappear off the
face of the earth.) But since my objection was to the logic of the rule rather
than its desirability, I withdraw the comment. 

Some explanation, to avoid other readers going through the same logical
contortions, might be desirable. For example, the rule could be rephrased to 

3. If the element declaration for ElementName in the in-scope element
declarations is not nillable, then the candidate node is not nilled. (Note: this
condition might not be satisfied if the schema contains local element
declarations for ElementName as well as the global element declaration.)

This seems to raise some issues that require discussion.

>On second thought, however, I think your original comment may be correct. If
the element in question were 
>validated against a local declaration that is nillable, then its type
annotation would correspond to that 
>local declaration, not to the global declaration named in the Schema Element Test.

But the types might be the same. 
 
I'm struggling with this. Consider the scenario: 
 
<xs:element name="e" type="xs:integer" nillable="false">
 
<xs:element name="f">
  <xs:complexType>
    <xs:sequence>
       <xs:element name="e" type="xs:integer" nillable="yes"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
 
let $f := validate strict { <f><e xsi:nil="true"/></f> } 
return ($f/e instance of schema-element(e)) 
 
The validation succeeds because the local e is nillable. The question I'm having
difficulty with now is, what is the type annotation on the e element? As far as
I can see from a careful reading of Schema Part 1 and the Data Model spec, e's
type annotation is xs:integer. Perverse, but that's what it seems to be. 
 
In applying the schema-element() test 
 
Rule 1 succeeds: the name of the candidate node is e.
 
Rule 2 succeeds: the type annotation is xs:integer

Rule 3 fails: the nilled property is not false, and the element declaration (the
global e declaration) is not nillable. But if the global element declaration had
said nillable="true", then rule 3 (and therefore the schema-element() test)
would succeed.

If this analysis is correct, then rule 3 does have some substance.

But I wonder what purpose is served by annotating e as an xs:integer in this
case? Why don't we say that if an element is nilled, its type annotation is
[absent] (or some similar nihilistic value)?

The Data Model section 3.3.1.2 says that if an element is annotated with an
atomic type T, then the typed value of the element is an instance of T. If my
reasoning above is correct, then this statement isn't true: the typed value of
<e xsi:nil="true"/> can surely only be ().

Mike

Bug reopened for further discussion based on new comments by Michael Kay.

After further discussion of this comment on May 16, 2005, the Query and XSLT 
Working Groups decided not to make any substantive changes to section 2.5.4.4. 
However, the following clarifying sentence was added to section 2.5.2, Rules 4a 
and 4b:
"However, if the nilled property of the node is true, then its typed value is 
the empty sequence."

Since you were a participant in the discussion, I will mark this comment as 
fixed and closed.