Status of The Catalog of Discretion

[David_Marston@lotus.com]

Here's where I think we stand on the effort to itemize and define all the
discretionary areas granted in the XSLT and XPath specs.

Overall, I hear nothing about consensus about what these items are: areas
where the spec has knowingly and explicitly allowed variations in the
behavior of XSLT processors. It's part of the way in which the notion of
"conformance" has some fuzz.

What we have so far is a catalog that intends to represent *all* the
discretionary areas. However, at last night's meeting there was a clear
sentiment to also generate a subset of that list to represent those areas
where some testing could happen. For now, we would concede that the rest
are either non-testable or cannot be tested in a first-round test suite.
One prime example is the discretion granted regarding infinite loops in
5.4: since vendors are never required to catch any infinite loops, we can
just let them brag if they do. It's nice to have a catalog of all the
discretionary areas, but most of the action will continue with the
test-worthy subset.

The new subcommittee on discretionary areas will try to weed out items in
the current list that aren't truly discretionary, at least eliminating
items where the processor behavior is confined to one course of action.
(There is a general discretion regarding the text of error messages, but
that is a separate concern.) A good example of one to include is conflict
resolution among templates, where Section 5.5 grants the developer two
possible courses of action.

Some broader areas, such as language-aware sorting, need to be expressed as
distinct items (e.g., per language) so that each can have a finite set of
discretionary choice values. In other words, the infinitely-extendable
areas need to have a naming scheme that allows us to name a few now and
establish an extendable structure so that more instances can be named
later. The "choice" values for any given named item would not be infinitely
extendable, and I think the subcommittee will define the details.

We need to name the discretionary areas, especially the test-worthy ones,
because the test catalog design depends on it. I expect that the
subcommittee will make a recommendation about whether the names have the
"disc-" prefix or not; the catalog doesn't care.

For each discretionary item that is test-worthy, we need to name all the
possible choices. Again, the test catalog design depends on this, as will
the mechanism that renders a test suite in light of the developer's design
choices. These can be readable strings rather than booleans, because the
rendering mechanism will reduce them to booleans when it matters. I expect
that the full committee will deal separately with the issue of providing
test cases covering all choices.

Now let's walk through an example. Chapter 10 of XSLT grants broad
discretion about sorting of the text data type, to accommodate language
differences. We would say that language-aware sorting is a "discretionary
area" from which the subcommittee will designate some "discretionary items"
for cataloging and rendering. Thus, we are able to get past the "no single
language is universally required" issue and have some tests of this area
while allowing for infinite extendability. Each designated language is
represented by a discretionary item that asks whether that language is
supported for sorting. A test case that uses xsl:sort with the text data
type would be annotated with the discretionary item for the language it
uses and a "yes" choice on that discretionary item. If the processor
supports sorting in that language, their answer of "yes" on that
discretionary item will match the "yes" in some of the test cases, and
those cases will be included in the battery for that processor.

I hope this properly defines the work of the subcommittee on discretionary
items.
.................David Marston