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 2420 - xsl:message treats a colision of select attribute and sequence-constructor in contentare different from other elements
Summary: xsl:message treats a colision of select attribute and sequence-constructor in...
Status: CLOSED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P3 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://www.w3.org/TR/xslt20/#element-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-26 20:13 UTC by Sergey Dubinets
Modified: 2006-03-08 21:45 UTC (History)
0 users

See Also:

Attachments

Description Sergey Dubinets 2005-10-26 20:13:32 UTC 
In XSLT 2.0 many instructions allow two alternatives in specifying content:
1. with optional select attribute.
2. with sequence-constructor as content.
In most of them attribute select and sequence-constructor are "mutually
exclusive"  (with more or less consisting wording of this fact).
xsl:variable, xsl:param, xsl:with-param, xsl:attribute, xsl:manespace,
xsl:comment, xsl:processing-instruction, xsl:value-of, xsl:sort, xsl:perform-sort.

xsl:message handles this collision differently: it allows both of them.

This looks like a bug in a spec.
Comment 1 Michael Kay 2005-10-31 13:14:16 UTC 
This isn't a bug in the spec: it was a conscious design decision, though one
that you are free to disagree with.

The reason it was done this way is that xsl:message is used mainly for
diagnostics, and it was thought undesirable that a diagnostic facility should
itself produce errors. Furthermore, one of the reasons that other instructions
aren't allowed to have both a select attribute and a content body is that it's
not obvious how the two should be ordered in the output; for xsl:message the
resulting order is likely to be of little consequence.

I've classified this as "LATER" so the WG will come back to it at some stage.

Michael Kay
personal response.
Comment 2 Michael Kay 2006-02-08 22:40:37 UTC 
We closed this just before going into CR, as we were not then in a position to
accept new comments. I am reopening it now for WG review and response as we
promised to come back to it later.
Comment 3 Michael Kay 2006-02-17 18:31:45 UTC 
The XSL Working Group discussed this comment at its meeting on 16th Feb 2006.

There were no strong feelings in either direction as to whether the language was
better with or without this change. In this situation, at this stage of the
development of the language, we stick with the status quo. I don't think many
users are going to hit problems because of this minor inconsistency, and a few
users might be saved a debug cycle.

I am therefore closing the bug report as "won't fix", indicating that we propose
to make no change to the specification. If you are content with this response,
please mark the bug report as closed; otherwise please supply further
explanation as to why the change needs to be made. If we don't hear from you, we
will close the bug report at the end of February.

Michael Kay
for the XSL Working Group