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 7596 - [XSLT 2.0] Definition of error XTSE0690
Summary: [XSLT 2.0] Definition of error XTSE0690
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows XP
: 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: 2009-09-12 23:59 UTC by Hans-Juergen Rennau
Modified: 2010-07-15 09:04 UTC (History)
1 user (show)

See Also:


Attachments

Description Hans-Juergen Rennau 2009-09-12 23:59:23 UTC
Maybe I just fail to understand the text. If so, perhaps the text could be clearer.

<quote>
[ERR XTSE0690] It is a static error  if a template that is invoked using xsl:call-template  declares a template parameter  specifying required="yes" and not specifying tunnel="yes", if no value for this parameter is supplied by the calling instruction.

[ERR XTDE0700] In other cases, it is a non-recoverable dynamic error if the template that is invoked declares a template parameter with required="yes" and no value for this parameter is supplied by the calling instruction.
</quote>

This sounds as if there were a special rule concerning the treatment of required=yes, applied when the template is called by call-template: as if a call not supplying the parameter would not provoke an error, if only the <xsl:param> had a further attribute tunnel=yes. However, this would hardly make sense, and it is not what I observe when testing with Saxon.
Comment 1 Michael Kay 2010-07-15 09:04:02 UTC
Sorry for the admin slip-up here: it seems this was one of a batch of bugs closed by a visiting vandal.

We believe the spec is correct and reflects the WG intentions. The idea is that there are two errors here: XTSE0690 is a static error, because call-template calls can be analyzed statically, while XTDE0700 covers apply-templates and other cases where the error can only be detected at run time.

I hope this explanation is satisfactory and am closing the bug as "INVALID".