Brian Minchau wrote: > I know that Xalan has some extension attributes for xsl:output ... but now > that I think about it ... where in XSLT 1.0 recommendation does it say that > this is OK?
XSLT section 2.1: "An element from the XSLT namespace may have any attribute not from the XSLT namespace, provided that the expanded-name of the attribute has a non-null namespace URI. The presence of such attributes must not change the behavior of XSLT elements and functions defined in this document. Thus, an XSLT processor is always free to ignore such attributes, and must ignore such attributes without giving an error if it does not recognize the namespace URI. Such attributes can provide, for example, unique identifiers, optimization hints, or documentation." So, you can add extension attributes as long as they don't change the specified behavior of the element. So for example it is wrong (even though Saxon does it) to have an extension attribute on a non-empty XSLT 1.0 xsl:variable element that causes it to create a node-set instead of a result tree fragment. But having xalan:location-info="no" on xsl:message wouldn't be harmful or against spec. I agree though that it'd likely be something people would want to control globally, as well as per-message. As for what I use xsl:message for: - debugging: often doing copy-of on a variable to see what it is - tracing: "got here"/"now doing X" kinds of messages that I want to be logged - validation: abort processing if crucial info missing; warn re: other issues Also in the debugging and validation veins, I often write stylesheets that walk a tree and process whatever is found. I'll set up templates to handle certain nodes, and a generic template that handles anything I forgot to create a more explicit template for. In that generic template will be an xsl:message saying something to the effect of "FIXME". A top-level param might be used to control whether the xsl:message is actually invoked. Mike
