W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2015

[Bug 27806] New: [xslt30] Error codes for xsl:context-item

From: <bugzilla@jessica.w3.org>
Date: Mon, 12 Jan 2015 12:58:13 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27806-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27806

            Bug ID: 27806
           Summary: [xslt30] Error codes for xsl:context-item
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

>From an email thread at
https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Jan/0003.html
(member-only):

On 4 Dec 2014, at 16:34, Abel Braaksma <abel.braaksma@xs4all.nl> wrote:

> Action item is a follow-up to https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Oct/0061.html, which discusses vague error conditions for xsl:context-item when the as-clause does not validate, or has a wrong / non-existing type.

MK responded:

Firstly, let's see what we currently say:

<xsl:context-item
  as? = sequence-type
  use? = "required" | "optional" | "absent" />

If the as attribute is present then its value must be an ItemTypeXP30. If the
attribute is omitted this is equivalent to specifying as="item()".

So the syntax requires a SequenceType, and the prose then restricts this to an
ItemType.

This seems a little clumsy; it would be better to use ItemType in the proforma,
and add this to the list of attribute types enumerated in section 2.2 Notation.

The error handling should be very similar to other attributes that expect a
SequenceType, for example xsl:variable/@as

The rules for validity of a SequenceType include

(a) basic grammatical correctness
(b) QName validity (prefixes in scope)
(c) type names are present in the in-scope schema definitions
(d) certain constructs make no sense unless the processor is schema-aware.

For (a) I would expect
[ERR XTSE0020] It is a static error if an attribute (other than an attribute
written using curly brackets in a position where an attribute value template is
permitted) contains a value that is not one of the permitted values for that
attribute

For (b) I would use
[ERR XTSE0280] In the case of a prefixed lexical QName used as the value (or as
part of the value) of an attribute in the stylesheet, or appearing within an
XPath expression in the stylesheet, it is a static error if the defining
element has no namespace node whose name matches the prefix of the lexical
QName.

For (c), I don't think there are special rules for other SequenceType-valued
attributes, so I would use XTSE0020.

For (d), the rules in 26.2 possibly need extending. I note, for example, that
there appears to be no error condition allowing a non-schema-aware processor to
reject <xsl:mode typed="yes">. I would be inclined to extend XTSE1660 as
follows:

[ERR XTSE1660] A non-schema-aware processor must signal a static error if a
package includes an [xsl:]type attribute; or an [xsl:]validation or
[xsl:]default-validation attribute with a value other than strip, preserve, or
lax; or an xsl:mode element with @typed equal to "yes" or "strict"; or an "as"
attribute whose value is a SequenceType that can only match nodes with a type
annotation other than xs:untyped or xs:untypedAtomic (for example,
as="element(*, xs:integer)").

The WG accepted MK's proposed solution.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 12 January 2015 12:58:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 12 January 2015 12:58:15 UTC