W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2014

[Bug 25517] [xslt 3.0] xsl:mode @typed=strict|lax

From: <bugzilla@jessica.w3.org>
Date: Mon, 14 Jul 2014 15:23:16 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-25517-523-h8gC2nsUz3@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25517

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
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.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 14 July 2014 15:23:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:47 UTC