2420 2005-10-26 20:13:32 +0000 xsl:message treats a colision of select attribute and sequence-constructor in contentare different from other elements 2006-03-08 21:45:12 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 2.0 Candidate Recommendation PC Windows XP CLOSED WONTFIX http://www.w3.org/TR/xslt20/#element-perform-sort P3 normal --- 1 sdubinets mike public-qt-comments oldest_to_newest 6922 0 sdubinets 2005-10-26 20:13:32 +0000 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. 6972 1 mike 2005-10-31 13:14:16 +0000 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. 8165 2 mike 2006-02-08 22:40:37 +0000 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. 8310 3 mike 2006-02-17 18:31:45 +0000 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