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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25517

            Bug ID: 25517
           Summary: [xslt 3.0] xsl:mode @typed=strict|lax
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

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.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25517

--- Comment #1 from Michael Kay <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25517

--- Comment #2 from Michael Kay <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25517

--- Comment #3 from Michael Kay <[hidden email]> ---
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.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25517

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Michael Kay <[hidden email]> ---
The proposal in comment #3 was accepted by the WG and has been applied to the
spec.

--
You are receiving this mail because:
You are the QA Contact for the bug.