Idea for a helpful appendix in future Recommendations

Included with this message is a document developed by the OASIS
Technical Committee (TC) on XSLT/XPath Conformance. We had to derive
the content by careful reading of documents issued by your Working
Group (WG). For XSLT 2.0 and other new documents from your WG, I think
you should issue the equivalent material, probably as a new appendix.

This document concerns allowable variances among XSLT processors. We
searched for occurrences of "should" and "may" in the 1.0 documents,
as well as reading-in-detail for grants of discretion. We had to assume
that each grant of discretion could be separately decided by the
developer of a processor, though you may have intended for groups of
these discretionary items to be implemented according to a single
policy. I hope that reading this document helps you think about how
you might want to constrain the choices.

If the verbiage is a little rough in spots, and if the organization of
the sections seems overly slanted to the needs of conformance testing,
please recognize that you are reading one output generated off an XML
foundation. We needed to inventory all aspects of discretion granted
to XSLT processors, and they have varying impacts on a suite of test
cases. I want you to focus on the content rather than its organization.

Please pay particular attention to add-attribute-to-non-element vs.
comment-non-text-content and PI-non-text-content. This is an area where
"opposite" choices on two items would expose a hole that requires yet
another decision of which decision aplies when both situations occur.
More concretely: XSLT subsection 7.1.3 allows a developer the choice of
throwing an error or ignoring an attribute requested within xsl:comment
(and other non-elements), and 7.4 offers the same choices for
xsl:attribute (and other non-text) within xsl:comment. There is no
requirement that the developer make the same choice in each case (each
case covering more than just the area of overlap), and if opposite
choices are made for the two, then there is a further decision about
which choice applies when xsl:attribute is nested inside xsl:comment.
I'm not opposed to "saying something twice" in a Recommendation; I just
see this as evidence that you must be careful about doing so.

If the WG assembles a list of all facets of discretion, it helps both
processor developers and conformance testers begin with a consistent
checklist. It may also help you convey your intent to these and other
audiences.
.................David Marston

(See attached file: newdisc.html)