Lists of Block Designs

A list of block designs is essentially what the name implies. However, the listed designs must be distinct, and we allow assertions to be made about this list; in particular, it will be possible to say

• the designs in the list are pairwise non-isomorphic;

• these are all the designs with such-and-such properties.

Here is the schema definition for the list_of_designs element which is the root element of any valid external representation document.

list_of_designs = element list_of_designs {
    attribute dtrs_protocol	     { "1.1" } ,
    attribute design_type            { "block_design" | "latin_square" } ,
    attribute pairwise_nonisomorphic { "true" | "false" | "unknown" } ,
    attribute no_designs             { xsd:nonNegativeInteger | "unknown" } ? ,
    attribute precision              { xsd:positiveInteger } ? ,
    list_definition ? ,
    ( block_design | latin_square ) * ,
    info ?
}

There are three compulsory attributes:

dtrs_protocol

It will be used by applications to check compliance of documents and of themselves. It must contain a fixed string representing the current protocol version of external representation schema.

In the future, the minor version number will be incremented when backward compatible minor changes have been made. That means that older documents satisfying previous protocols with the same major version number remain valid under the new protocol. The corresponding requirement for implementations is that an implementation in compliance with a given protocol version should be able to deal with any document of the same major and a lower protocol version.

The major version will be incremented between not entirely compatible versions or when significant new structures have been introduced.

design_type

Currently the only implemented design type is (binary) block design which is indicated by the string ``block_design''.

pairwise_nonisomorphic

This is ``true'' if the designs in the list are known to be pairwise non-isomorphic, ``false'' if they are known not to be, and ``unknown'' otherwise.

The optional list_definition component will be used to define list invariants and to formulate queries to the database. These concepts are the subjects of future development.