image_cardinality and b and no_designs

[Peter Dobcsanyi]

On Tue, Aug 05, 2003 at 06:05:09PM -0400, John P. Morgan wrote:
> The attribute "image_cardinality" has been removed from
> "function_on_ksubsets_of_indices".

and also from function_on_ksubsets_of_indices

> Could someone please explain why (checked the log but was unable to
> determine the history of this change)?

It happened at revision 1.47 with the big structural change introducing
"combinatorial_properties".  "image_cardinality" was a minor thing
discussed to death here in London at personal meetings before and I
forgot to mention it in the log.

> Has the necessity of this information changed since its adoption
> during one of our Spring meetings?

Just to recall: the necessity could come from using it in queries when
forming list-invariants.  So the answer is: well not really, but since
then considerable doubt surfaced about the way expressing it this way.
There were two reasons for that.

1) The definition of list-invariants is in a very early phase of research
and keeps changing. (List invariants won't be in the final version 1.0
protocol, just a slot for them.)

2) Removing "image_cardinality" was part of a larger campaign of mine to
clean up complex (as opposite to empty indicator like) elements whose
attributes duplicate information otherwise easily available from the
content of the element (or the enclosed subtree).  "easily" means the
application programmer can access it from the underlying system with a
call practically without any application level computing.

Apart from "image_cardinality" in functions, there are two other cases I
am not happy about in this respect:

    attribute b in <block_design>
    attribute no_designs in <list_of_designs>

Yes we duplicate information at many other cases in the ext-rep, however
in the other "clean" cases there is always the option either to use the
compact indicator form or a different complex element giving the same
and much more information. Take as an example "equireplicate" contrast
to a full blown "point_concurrences". One can use both if he likes,
though maybe it is not the best policy. The point is the information is
not duplicated in the same element.

Since I am still a long way to list-invariants and do not want to
throw out the baby with the bath-water, I implement a compromise which
will also keep the Writer implementors happy:

    - put back the "image_cardinality" in functions
    - make all aforementioned problematic attributes optional 

--             ,
    Peter Dobcsanyi