Test Assertion for SpecGL CP 5.2

The checkpoint:
Checkpoint 5.2.
For implementation dependent values or features, address the allowable
differences between implementations[Priority 1]
Conformance requirements
The specification MUST describe any permitted variations or constraints
for how the implementation dependent value or feature is realized by
implementations.

The proposed Test Assertion:
If implementation dependent values or features exist THEN, for each
implementation dependent value or feature, the specification describes any
permitted variations or constraints for how the value or feature is
realized by implementations.

Previous discussion (from Dec. 22 minutes):
>Issue:  DM raised issue about "obviousness".

>Discussion:  "Allowable differences" could go arbitrarily deep and is 
>potentially an open-ended (and unimplementable) requirement.  No 
>suggestions how to do it, but some threshold of directness or obviousness 

>would be nice, to limit the open-ended-ness.

>Decision:  deferred to email.  (DM will launch email discussion.)

Okay, let's start by illustrating the range that's possible:
A. The product-under-test takes some XML as input and is given latitude
   about acceptable forms of the input (e.g., SAX events vs. a file it
   parses), *but* it must only use valid InfoSet properties.
B. Where URIs are used, the product may support any scheme it wants to,
   and in particular is not required to support HTTP. However, there is
   a tacit assumption that at least one scheme is supported.
C. Any XML document encodings can be supported, as long as at least one
   of UTF-8 and UTF-16 is. The default encoding is entirely discretionary.
D. Data types beyond the ones in XML Schema Part 2 can be supported, but
   "support" does not necessarily mean that the type can be sorted,
   rendered as a string, etc. as we expect for the known types.
E. Extension functions can be added to the set of available functions,
   but they must be in non-W3C namespaces. The number of such namespaces
   devoted to extension functions is unlimited.
F. The assumed timezone of a time value lacking one is discretionary,
   but it must be one of the valid timezones.
G. When a URI references an invalid XBlah instance, the product may
   throw an error or continue with a default XBlah, but the specific
   default depends on some other discretionary choice. The default
   must be type A for choice A and the empty document node for choice
   B of that other choice item.

The person attempting to evaluate the test assertion can recognize the
constraints when they are stated in the immediate context of the
statement that the item is discretionary, as written above. If the reader
found a constraint somewhere in the spec that was *not* mentioned in the
enumeration of discretionary items, then we probably have a spec that
fails this checkpoint. However, if you just read the enumeration of the
discretionary items, you don't see what's not mentioned.

When assessing whether "any permitted variations" have been described,
examples B, C, E, F, and G are probably clear enough. I'm a little
less sure about A and D; it depends on the verbiage actually used. Of
course, B is suspect because of the tacit assumption.

When assessing whether "any constraints" have been described, examples
A, E, D, and G are probably clear enough, assuming that a reading of
the whole document confirms that every applicable constraint was
presented where the discretionary item was presented. Examples B and D
might not say enough about the minimal expectations.

Example C raises the question about depth of probing when evaluating
the document. If UTF-16 is supported, and especially if it's the
default, then it may matter whether big-endian or little-endian byte
ordering is issued. Is the evaluator required to have that much
domain-specific knowledge? If so, then anyone reading a spec for
purposes of scoring it against the SpecGL TAs must know what is
"obvious" to practitioners in that domain. Example G, on the other
hand, limits its depth to other aspects of the same spec.

I believe that 5.2 is enforceable, to the extent that constraints
are written down at all. The issue is about how far afield the
evaluator must look for potential constraints. Since this is SpecGL, I
would say the range is either the one spec or the family of specs of
which it is a member. Broader constraints can be detected during
substantive reviews associated with Last Call and CR.
.................David Marston

Received on Thursday, 8 January 2004 16:50:32 UTC