This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The rules for xsl:mode/@typed say: The value strict is equivalent to yes, with the additional provision that within the match pattern of every template rule in this mode, any NameTest used as an AbbrevForwardStep (with no preceding "@") in the ForwardStepP of the first StepExprP of a RelativePathExprP is interpreted as match="schema-element(product)", while match="product/code" is interpreted as match="schema-element(product)/code". The value lax is equivalent to strict, except that the interpretation of a NameTest as a SchemaElementTest occurs only if it matches the name of a global element declaration in the in-scope schema declarations. Several problems here: (a) there's an abrupt lurch into specification by example; it's clearly not intended that EVERY Nametest is to be interpreted as schema-element(product)! (b) patterns now allow the child axis to be written explicitly, we should recognize this case also. (c) a NameTest can be a wild card, but this doesn't convert to a schema-element test. Suggested replacement rule: The value strict is equivalent to yes, with the additional provision that in certain contexts within the match pattern, a bare element name E is interpreted as schema-element(E), meaning that it will only match an element that has been validated against the declaration of element E in the schema. Specifically, in any RelativePathExprP within the pattern, if the first StepExprP satisfies the following conditions: 1. the principal node kind of the axis used in the axis step is Element (that is, the axis is not the attribute or namespace axis) 2. the NodeTest used in the axis step is an EQName then the EQName used as the NodeTest in this axis step (say E) is replaced by a SchemaElementTest using the same EQName (in this case schema-element(E)). The value lax is equivalent to strict, except that the substitution of a SchemaElementTest only takes place if there is a global element declaration in the schema with a matching name.
The existing text also uses the phrase: the match pattern of every template rule in this mode which is not quite precise enough. In the case where a template rule applies to several modes, the pattern used for matching in other modes is unaffected; this substitutation/refinement of the pattern is local to the mode on which the @typed attribute appears.
Further observation. If there is no element declaration E in the schema, then writing schema-element(E) would be an error; it is meaningless. Therefore, generating schema-element(E) seems a bad idea. We could interpret it as generating a pattern that never matches anything, but why would we want to do that? It makes more sense, I think, to treat the pattern as an error in such circumstances, just as if the user had written schema-element(E) explicitly.
I took an action to propose detailed wording. Firstly, since we have editorial problems creating table cells containing multiple paragraphs, I intend to create a new section to describe the possible values of the xsl:mode/@typed attribute, and reference this from the table of attributes. Draft text follows: The typed attribute of xsl:mode informs the processor whether the nodes to be processed by template rules in this mode are to be typed or untyped. * If the value yes is specified (synonyms true or 1), then all nodes processed in this mode must be typed. A dynamic error occurs if xsl:apply-templates in this mode selects an element or attribute whose type annotation is xs:untyped or xs:untypedAtomic. * If the value no is specified (synonyms false or 0), then all nodes processed in this mode must be untyped. A dynamic error occurs if xsl:apply-templates in this mode selects an element or attribute whose type annotation is anything other than xs:untyped or xs:untypedAtomic. * The value strict is equivalent to yes, with the additional provision that in the match pattern of any template rule that is *applicable* to this mode, any NameTest used in the ForwardStepP of the first StepExprP of a RelativePathExprP is interpreted as follows: ** If the NameTest is an EQName E, and the principal node kind of the axis of this step is Element, then: *** It is a static error if the in-scope schema declarations do not include an element declaration for element name E *** When matching templates in this mode, the element name E appearing in this step is interpreted as schema-element(E) (informally, this means that it will only match an element if it has been validated against this element declaration). ** Otherwise (the NameTest is a wildcard or the principal node kind is Attribute or Namespace), the template matching proceeds as if the typed attribute were absent. * The value lax is equivalent to yes, with the additional provision that in the match pattern of any template rule that is *applicable* to this mode, any NameTest used in the ForwardStepP of the first StepExprP of a RelativePathExprP is interpreted as follows: ** If the NameTest is an EQName E, and the principal node kind of the axis of this step is Element, and the in-scope schema declarations include an element declaration for element name E then: *** When matching templates in this mode, the element name E appearing in this step is interpreted as schema-element(E) (informally, this means that it will only match an element if it has been validated against this element declaration). ** Otherwise (the NameTest is a wildcard or the principal node kind is Attribute or Namespace or there is no element declaration for E), the template matching proceeds as if the typed attribute were absent. * The value unspecified is equivalent to omitting the attribute, and places no constraints on whether the nodes to be processed in this mode are typed or untyped. (Add definitions of error codes as necessary.)
The proposal in comment #3 was accepted by the WG and has been applied to the spec.