More about handling discretionaries

[David_Marston@lotus.com]

I wrote:
>The <Discretionary> element occurs zero or one time as a
>child of the <TestCase> element, and it has one or more children
>if it occurs. JR will take the lead in "DTDifying" this and the rest
>of the design, and he or other committee members may want to change
>to an attribute-oriented scheme. At this stage, we need Tony and
>anyone who might run the tests to advise whether element or
>attribute orientation makes a difference in how test cases are
>excluded.

To which Tony replied:
+If the answer to the question is in an attribute value, then we can
+control the allowed values (where we want controlled values).
+
+Considering Saxon's three levels of user control over signalling
+errors, there could be multiple ways of modelling a discretionary
+item....

But the spec (Section 5.5) only recognizes two ways of dealing with
the signal-unresolved-template-rule-conflict discretionary item,
which I abbreviated to "choose-last" and "error". If the signal from
a conflict is non-fatal, it's irrelevant to conformance testing,
because it means that the developer elected "choose-last" as their
way of dealing with the conflict. Once we know they've made that
choice, we must include the test case whose catalog entry says
<Discretionary>
  <signal-unresolved-template-rule-conflict>choose-last
    </signal-unresolved-template-rule-conflict>
</Discretionary>
or, in another format,
<Discretionary>
  <signal-unresolved-template-rule-conflict option="choose-last"/>
</Discretionary>
and we don't care about the warning message, we just care that the
last template was chosen. The operational scenario is to compare the
output files rather than capture a message to StdErr. Naturally, we
exclude that other test case whose catalog entry says
<Discretionary>
  <signal-unresolved-template-rule-conflict option="error"/>
</Discretionary>
or equivalent.

The attribute-oriented design does indeed have the advantage of an
enumerated list of choices. If every one of the discretionaries has
a limited list of keywords, then we can decide to go with that design,
as long as extraction of the data from the catalog is easy enough.
So we ought to be reviewing the set of discretionaries to see if all
can be represented as multiple-choice, possibly requiring some items
to expand to more than one question. Personally, I don't see any gain,
and I see a loss of readability, if we push beyond multiple-choice
and keywords to simple yes/no. Now what happens if we can't encode
every item as a choice among keywords? Do we go to an element-centric
design for symmetry, or do we allow different sub-elements of the
<Discretionary> element to have different designs?

By the way, we could name every sub-element the same, as in:
<Discretionary>
  <item OASIS-name="signal-unresolved-template-rule-conflict"
    option="error"/>
</Discretionary>
Again, this can be decided according to what makes it easiest to
exclude cases.
.................David Marston