[Image] [Image] [Image] [Image]

RFC 2.0 compliance

In some areas, the RFC 2.0 specification does not take a position and therefore additional decisions had to be taken; these are outlined below and documented at the appropriate places in this document.

The Zdatr 2.0 engine is RFC 2.0 compliant. The notion ``RFC 2.0 compliant'' is taken to mean that all the objects defined in DATR Standard Library RFC 2.0 except #bool and #nc are implemented as defined there. It is not taken to mean that only the objects defined DATR Standard Library RFC 2.0 are implemented, and where there is no RFC 2.0 specification further decisions had to be made. Details of the extensions are included in the present document.

The overriding requirements specification in the development of Zdatr 2.0 was to establish compatibility with the other major implementations such as Sussex DATR (Universities of Brighton and Sussex), QDATR (Universität Düsseldorf). Intensive efforts were made in order to achieve this goal, including intensive direct and email discussion with Gerald Gazdar and Roger Evans (as Sussex DATR and RFC 2.0 authors), and a one-day workshop in Bielefeld with Dafydd Gibbon, Grigoriy Strokin (as Zdatr authors), Christoph Stumpf and Sebastian Varges (as QDATR authors). On this basis some additional implementation decisions where were taken:

1. Non-RFC 2.0 compliant syntax: The QDATR { ... } abbreviation for a set of equations for each member of all the permutations of the LHS path will be replaced by << ... >> as a contribution to character set compatibility. In Zdatr 2.0 this convention generates a syntax error; the present authors would prefer to see a pre-processor used to spell out the permutations and thus ensure compatibility with other implementations.
2. RFC 2.0 compliant syntax: The hard lop operator which blocks the extension operation in DATR inference, (also known as chop, path cut, `ugly atom') is imlemented as `.' If only declared variables are used, then its behaviour is identical to the soft lop using an `unknown atom', i.e. an atom which never occurs on the LHS of a DATR theory, but if on the fly variables are used this is clearly not the case, because unknown atoms connect to variables.
3. Non-RFC 2.0 compliant directive omission: The #bool directive is not implemented, for technical simplicity in implementation while preserving compatibility between Boolean and arithmetic. The default values suggested in RFC 2.0, i.e. 0 and 1 are used for the Boolean library functions.
4. RFC 2.0 extensions: A number of arithmetic, string, meta-object and I/O extensions are included for practical purposes in upscaling theory and query sizes. Most may be regarded as abbreviations for existing definitions. But some, while not contradicting RFC 2.0 specifications, may be termed `non-conservative'. These include the devices for accessing the current nodes in the DATR evaluation environment, as required in the formalisation of Network Morphology and a number of other DATR applications. Another is the CALC node with extended arithmetic and trigonometric operator atoms for the statistical processing of large data sets.

[Image] [Image] [Image] [Image]