This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30234 - [XSLT30] Section 25.4.1.2 on [xsl:]type, and XTSE1520 talk about QName, but syntax allows EQName; enumeration of instructions is not complete
Summary: [XSLT30] Section 25.4.1.2 on [xsl:]type, and XTSE1520 talk about QName, but s...
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-25 09:24 UTC by Abel Braaksma
Modified: 2019-02-19 21:16 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2018-03-25 09:24:27 UTC
Section 25.4.1.2 starts as:

"The [xsl:]type attribute takes as its value a QName."

The error XTSE1520 is currently defined as:

"[ERR XTSE1520] It is a static error if the value of the type attribute of an xsl:element, xsl:attribute, xsl:copy, xsl:copy-of, xsl:document, or xsl:result-document instruction, or the xsl:type attribute of a literal result element, is not a valid QName, or if it uses a prefix that is not defined in an in-scope namespace declaration, or if the QName is not the name of a type definition included in the in-scope schema components for the package. "


I see two issues with this:

1) The definitions of the type attribute throughout the specification use consistently the eqname production. This error, nor this section, don't.

2) The list doesn't mention xsl:source-document, xsl:merge-source, which both can also take a type attribute.

I propose we add an item in our Erratum that the text should be updated to reflect that we allow an EQName, and that this error also applies to these other two instructions.
Comment 1 Abel Braaksma 2018-03-25 09:25:01 UTC
> don't.
doesn't ;).
Comment 2 Abel Braaksma 2018-03-25 09:48:20 UTC
Perhaps we should also mention that "Q{}somename" will not be bound to the default element/type namespace (at least, I think it shouldn't), where "somename" (i.e., name without prefix) would.
Comment 3 Abel Braaksma 2018-04-03 23:36:24 UTC
Please disregard comment#2, this is described at length in sections 5.1.1 and 5.1.2.
Comment 4 Abel Braaksma 2019-02-19 21:16:55 UTC
A draft erratum E20 was published on Feb 13, 2019, HTMl version: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E20