This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
During validation, elements in instances are bound to element declarations either because the user indicated that that should happen, when calling for validation, or because the context (both the document context and the validation context, and their interplay) determined a declaration to which the element should be bound. Among the latter, some bindings are direct (the expanded name in the content model matches the expanded name on the element), and others are indirect (substitutable elements, elements matching wildcards). Ditto for attributes. The term 'context-determined declaration' seems a natural one to use for those declarations which are determined by context, as opposed to being determined by the caller. But there are two problems. First, not every declaration determined by context is a context-determined declaration as that term is defined in 1.0 and in the 1.1 status quo. Declarations which match directly, or indirectly via element substitution, are context-determined declarations; declarations found via QName resolution, when an item matches a wildcard, are not. Second, and more serious, not every context-determined declaration is a declaration. Some of them are keywords ('mustFind', 'skip'). Note that the three-way distinction among strict, skip, and lax wildcards is formalized by a distinction among the context-determined declaration 'mustFind', the context-determined declaration 'skip', and no context-determined declaration at all. Either a rationale for the current usage should be enunciated (whether recovered from memory or manufactured from whole cloth) and documented in the spec, to make it easier for readers, or else the usage should be rationalized. One good step would be to stop using a term whose head noun is 'declaration' to denote things which are not declarations.
The problems with the term 'context-determined declaration' are part of a larger complex of problems, which I suggest we treat as the same issue, for tracking purposes. The relationship among the terms - context-determined declaration - local type definition (that is, the one identified by xsi:type, not one that's local to an element) - Test[ES,R] - governing type - locally determined type (and possibly others) needs to be clarified. It's possible that some of these terms should be replaced by other terms more suggestive to the reader. Some should perhaps be eliminated as redundant, unnecessary, or confusing.
A wording proposal to address this issue was adopted by the Working Group on 13 October 2006. With the adoption of this proposal, the usage of the terms mentioned in comment #1 has been simplified somewhat and the problems outlined in this issue have, I hope, been addressed. The term 'context-determined declaration' is now used only of declarations; keywords are no longer viewed as context-determined declarations. The instance elements formerly characterized as having context-determined declarations of 'mustFind' or 'skip' are described, in the current status quo text, as those attributed to strict or lax wildcards. The term 'local type definition' has been replaced with the term 'instance-specified type definition'. (There is a residual problem here: the current definition requires that the value of xsi:type be a QName and that the QName successfully resolve to a type definition. So the term provides no help for places where we need to describe xsi:type attributes whose value fails to resolve. But for the moment, that problem seems bearable.) The term Test[ES,P] has been replaced with the term 'default binding'. The WG and editors continue to desire a better term, but for now we conclude only that 'default binding', whatever its faults, is at least slightly more suggestive that 'Test[ES,P]'. The recently introduced terms 'governing type definition' and 'governing declaration' appear to be proving useful and have made it possible to simplify the formulation of several constraints. The term 'locally determined type' does not appear in the status quo; it was introduced in a draft proposal for bug 2544. The revised version of that proposal uses the term 'context-determined type', by analogy with the 'context-determined declaration'. Informally, if an element COULD (given an appropriate sequence of preceding siblings) have some declaration D as its context-determined declaration, then the {type definition} of D is the element's context-determined type, independent of its siblings. The EDC constraint guarantees that each element in a document has at most one context-determined type. With the adoption of the proposal yesterday, this issue appears to have been resolved; any residual or new issues relating to the terminology of context-determined declarations should be raised and tracked as distinct issues. Accordingly, I am marking this issue resolved.