Regarding examples and normativity:
DM>>If you look at the examples in context, the typical
DM>>presentation is: given this, it must do that. In other words, they
DM>>are more like test assertions.
LH>Just to make sure I'm not missing the point, can you point us to
LH>one specific such case (chapter/verse) in XSLT 1999?
Here is a motley collection of cases where the "example" conveys
crucial information.
In section 2.5, there is a paragraph beginning "Thus, any XSLT 1.0
processor must be able to process the following stylesheet without
error,..." and then gives example code.
The patterns given as examples in 5.2 MUST work as stated, which
could arguably be seen as clarification. One can probably derive a
normative statement from other material for each of them, but I know
that the WG was partly driven by example. In other words, they knew
that they wanted "text()" to match any text-node child, and they
built a syntax that would support that and other "examples" of what
they wanted.
In 5.4, the first NOTE (using <div> elements) includes a testable
sentence found nowhere else, and an example that is a borderline
test assertion.
In 7.5, the example of an identity transformation is treated as
normative by many, though it's arguable whether it actually nails
down any technicalities of node ordering.
Multiple-level numbering is under-specified in 7.7, so the examples
serve as normative clarification.
In 16.2, there is a paragraph and example about outputting boolean
attributes in "minimized form" but the term is not defined nor is a
normative definition cited from elsewhere. Thus, the example gives
information about what the term means.
These are all cases where the editors might have been more precise
about normativity if they had been aware of SpecGL issues at the
time the spec was developed. If a reviewer were to assume that all
examples are informative unless stated otherwise, then this spec
would fail the checkpoint about clearly distinguishing normative
from informative material.
.................David Marston