Granularity of spec citation

[David_Marston@lotus.com]

(I'll be talking about this stuff at XML 2000, so this is a way to get
started on my presentation.)

We look at the W3C recommendations as the basis for conformance testing,
and we naturally gravitate to sentences that translate readily into test
cases. For example, consider this sentence from the XPath recommendation,
Section 2.3:
"It is an error if the QName has a prefix for which there is no namespace
declaration in the expression context."
Since the positive cases are covered in preceding sentences, this one
sentence spawns one test case: create an XPath expression where we have a
node test (the subject of 2.3) with an unknown prefix and see if an error
is raised.

It sure would be nice if "the specs" consisted of nothing but
straightforward sentences like that. The next level of complication is the
compound sentence that, as a single sentence, spawns a "cross product" of
its provisions. Here's an example from Section 3.7 of XPath:
"If the character following an NCName (possibly after intervening
ExprWhitespace) is (, then the token must be recognized as a NodeType or a
FunctionName."
which yields four explicit cases:
NCName which is a NodeType - no space - (
NCName which is a NodeType - white space - (
NCName which is a function - no space - (
NCName which is a function - white space - (
and implies two negative cases:
NCName which is neither - no space - (
NCName which is neither - white space - (
Both of the negative cases should raise an error like "unknown function."

Furthermore, the above example also forces us into a cross product with
another part of the spec, because "NodeType" is actually a fixed list of
four words. So the first two test cases need to cite not only XPath 3.7,
Paragraph 3, Bullet Item 2, but also XPath Production 38, and may actually
become eight cases instead of two. On the other hand, we could probably
make a simplifying assumption about the treatment of whitespace and cut
that eight back to five. (We want to have at least one instance where we
see the same NodeType both with and without whitespace following, to be
sure that we isolate the effect of whitespace.) The cases can contain
comments pointing to both provisions in the spec, using our highly-granular
pointers.

All of the above deals with situations that boil down to an NCName followed
by an open parenthesis. Other bullet items describe interpretation rules
for a few of the syntactic elements that can follow NCName, but not all.
Fortunately, Paragraph 3 in its entirety covers all the situations where an
NCName is treated as a magic word (axis name, function name, operator,
NodeType), leaving the situations where the NCName is just the
user-assigned name of an entity (element, variable, etc.).

Now let's examine one last example of the compounding effect, this time
from XSLT 16.4:
"It is an error for output escaping to be disabled for a text node that is
used for something other than a text node in the result tree. Thus, it is
an error to disable output escaping for an xsl:value-of or xsl:text element
that is used to generate the string-value of a comment, processing
instruction or attribute node; it is also an error to convert a result tree
fragment to a number or a string if the result tree fragment contains a
text node for which escaping was disabled. In both cases, an XSLT processor
may signal the error; if it does not signal the error, it must recover by
ignoring the disable-output-escaping attribute."

You can see how many times the word "or" spawns different test cases, but
there's more. There's a discretionary choice for the processor developer,
and that too probably forms a cross product: error/ignore for xsl:value-of,
error/ignore for xsl:text, error/ignore for converting an RTF. I read this
to mean that the developer can make separate decisions on each, though I
certainly hope they make the same error/ignore choice for all. There's a
more obscure crossover with various parts of Chapter 7, because the above
paragraph imposes restrictions on the simple "Content: template" that you
see for xsl:comment and its brethren. These restrictions extend the
restrictions seen in 7.4 (Creating Comments) and similar sections. In other
words, the behavior when trying to disable output escaping on xsl:value-of
text going into a comment can be viewed as an aspect of
disable-output-escaping (the spec takes this point of view), as an aspect
of xsl:comment, or as an aspect of xsl:value-of. In the test cases, the
pointers into the spec should point to all sections with equal weight, and
there should be a flag in the test cases to associate the cases with
discretionary items as well.
.................David Marston