/ data / common-syntax

Conformance

This page can be safely skipped by the casual reader.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

A RULE is a conformace criteria where the imperative is MUST, MUST NOT, SHALL, SHALL NOT, or REQUIRED. A RECOMMENDATION is a conformace criteria where the imperative is SHOULD, SHOULD NOT, or RECOMMENDED. Adapting the notation of the Conformance section of the Character Model for the World Wide Web (hereafter CharMod), we say

• A specification, let's say S1, extends this spec (i.e., is a conforming extension of this spec) if it does not violate any RULE preceded by [Spec].

• An extension of this spec, S1, defines conformance criteria for specifications, for source text, and for various kinds of software for handing source text. To aid the reader, all conformance criteria are preceded by '[X]' where 'X' is one of

  • 'Spec' for specifications
  • 'Src' for source text
  • 'Producer' for producers -- software for producing source text output
  • 'Validator' for validators -- software that reads source text input and either accepts it or rejects it.
  • 'Advisor' for advisors -- software for reporting warnings about source text input

  Any of these conform to an extension of this spec, S1, if it does not violate any RULE preceded by '[X]' (for the appropriate 'X') in either this spec or in S1.

[Spec] A spec MUST document the reason for any deviation from a RECOMMENDATION.

[Producer] For a producer to conform to spec S1, the source text it produces MUST conform to S1.

[Validator] A validator for spec S1 MUST reject source text that does not conform to S1. The validator SHOULD report an informative enough problem to help a human diagnose the violation, including source position if possible.

[Validator] A validator for spec S1 SHOULD accept source text that conforms to S1. If the validator rejects source text for reasons other than lack of conformance with S1 (whether the text actually conforms or not), the reported problem MUST clearly indicate the fault lies with the validator rather than the source text. For example, a validation attempt MAY enounter resource limits in a validator that are not reflected in the spec.

[Advisor] An advisor for spec S1 SHOULD report a warning about source text that deviates from any RECOMMENDATIONS in S1. The warning SHOULD be informative enough to help a human diagnose the violation, including source position if possible.

[Spec] A spec MUST therefore only state source text conformance criteria that are feasibly computable (given adequate resources).

Rationale

The E family is intended to support secure programming and adversarial code reviews. The authors of the source text, the reviewers reading it to understand what it might do, and the owners of the language processor on which it runs may all be mutually suspicious parties with somewhat divergent interests. The conformance criteria on source text are designed to enable these parties to safely cooperate by use of these source texts. If source-author (or source-producer-author) Arthur has a reasonable expectation that a violation by Arthur's source text might not be caught by code reviewer Raven or language processor host Hazel, then Arthur may choose to violate that rule, independent of the wording in standards documents such as this.

For her own protection (and for the protection of those who rely on her), Hazel's language processor should only load code that has been accepted by a conforming validator. Likewise, when Raven reviews Arthur's source text, for her own protection (and for the protection of those who rely on her), Raven should examine the source text together with the diagnostics produced by conforming validators and advisors regarding that source text. (By "code review", we don't necessarily mean a formal process. Every time Raven looks at code in her IDE, she's reviewing code. It would be good for IDEs to incorporate conforming validators and advisors.)

Dependencies and Versions

Some of the E family of languages -- the E language, Kernel-E, and TermL -- delegate aspects of their specifications to other specifications, such as this page. This page in turn delegates to yet other specifications, such as Java, Unicode, and various IETF and W3C standards. This page currently intends to support the specifications of the E family as of the upcoming E 0.9 release (also to be known as E alpha). For each E release, the Version Dependencies Table to the right specifies the minimal version of these other standards it depends on.

• [Src] Source text written for a given version of E MUST conform to that version of the E spec interpreted in light of the specified minimum versions of the dependent specifications.
• [Src] Within the limits of knowledge avalable at the time, source text SHOULD be compatible with that version of the E spec interpreted in light of the minimal versions of the dependent specifications or later.

For example, the E language 0.9 spec depends on Java 1.3.1 or later. Therefore, an E 0.9 program SHOULD also be compatible with, for example, the E 0.9 spec interpreted in light of the Java 1.5 spec. Below, we generally leave out the version number of dependent specifications, and try to link to the latest relevant version of each one. Please consult this Version Dependencies Table for the actual minimal dependencies.

[Spec] Note the combinatorial effect: E 0.9 depends on Unicode 4.0 and Java 1.3.1. Java 1.3.1 in turn depends on Unicode 2.1, so, by implication, to conform to the E 0.9 spec, one MUST conform to Unicode 2.1 through 4.0, and SHOULD conform to Unicode versions after 4.0.

Besides covering E 0.9, we will also explain how we hope to evolve in upcoming E releases, and discuss the potential compatibility implications.