All,
Sent on behalf of Dave Kemp:
===== tear line =====
- I do have a question. One of the reasons for the discussion and the "text beats schema" wording is that the schema is not as complete as the text (at least in the Language Spec). In particular there are statements in the text not represented in the schema.
If the schema is the "more normative" text, would that mean the additional text constraints do not need to be met?
The schema contains the content of the tables in Section 3 of the Language Spec, and those tables are generated mechanically from the schema by a script. The schema does not have anything to do with text outside of the tables, so it does not supersede
or invalidate or conflict with that text.
In addition, the table Description column generated from descriptive text in the schema is non-normative, which is one of the reasons comments are stripped from Annexes A and B of the document. Normative requirements not represented by the syntax appear
in the text of the document, not in the syntax table comments.
In cases where the text DOES duplicate the schema, e.g. from Section 3.3.1:
Usage Requirements:
- Each command MUST contain exactly one action.
… the table and the schema say that the cardinality of action is 1. So in the event of a conflict, both the table and the schema are authoritative over any redundant requirements contained in the text.
- It’s the automated testing of valid messages that I was worried about. I was worried you could claim passed just on the schema even if it violated a statement in the text. But my reading of your email is in text, not in schema doesn’t count as not in schema
wins.
Yes.
- If the text conflicts with a table (by attempting to permit something syntactically invalid), the table (and the schema) win.
- If there is no conflict because the text restricts something permitted by the table (and schema), then any normative requirements contained in text apply.
- Text that does not state a normative requirement doesn’t affect conformance.