<resolutions>

[Peter Dobcsanyi]

On Mon, Jul 21, 2003 at 05:14:40PM +0100, Peter Cameron wrote:
> This opens a larger can of works. Should a list of designs containing
> no pairwise isomorphic designs be ordered? In theory, yes, and the
> obvious way to do it is to take the lexicographically least element
> in each isomorphism class and order these by the usual rules. But that
> is a fair amount of work...

I agree, it would be to much work to pick the appropriate representative,
even when we generate the list ourself, not to mention a "contributed"
list of designs.  Also we need to consider lists when
pairwise_nonisomorphic="unknown" (OK, I know this "unknown" is still
pending in general).

I think the list of designs should be ordered in both cases if the media
of an ext-rep document is a file (that is something which has a definite
begin and end). The ordering rules could be:

    - first by v	- as a measure of "size" of a design
    - then by <blocks> using lexicographic ordering

    Note:

	- the blocks as a subtree are already ordered by our canonical
	  ordering
	
	- of course a block design could contain much more subtrees than
	  <blocks>, but we just ignore the rest and takes only blocks as
	  significant components when ordering designs.

However, the ext-rep is a communication protocol not just a file format.
For example two programs might use it over a pipe: the first (say
Leonard's design package) generating designs with no guarantees about
isomorphism and the second (say my noniso program) filters the stream by
isomorphism. So, in general, we cannot always order a list of designs,
consequently the status of ordering should be indicated in a mandatory
attribute of the list:

    list_of_designs = element list_of_designs {
	attribute design_type { "block_design" | "latin_square" } ,
	attribute pairwise_nonisomorphic { xsd:boolean | "unknown" } ,
	attribute no_designs { xsd:nonNegativeInteger } ,
	
	attribute ordered { xsd:boolean },

	list_definition? ,
	( block_design | latin_square )+ ,
	info?
    }

--             ,
    Peter Dobcsanyi