functions - summary

[Peter Dobcsanyi]

This is the summary of the current status of function protocol of the
ext-rep.  What follows was reached through personal discussions with JP
and Leonard.  We've just got tired of writing :-)

In this post I use the following conventions describing the different
kind of functions:

    function		for "real" functions
    quasi function	when preimages have been collapsed
    extended function	referring for either kind
    <function_on...>	referring for both <function_on_indices>
			and <function_on_ksubsets_of_indices> either kind

In short, the conclusion is:

    - Extended functions are to stay and to be used generally.

    - Functions are ordered by the preimages using the canonical ext-rep
      ordering (length, lexico-graphic).  Quasi functions can optionally
      preserve this natural order but they are not required to do so. The
      status of ordering must be explicitly indicated.

    - Problems arising from using approximations for certain values are
      dealt explicitly within the ext-rep. Implementation details are
      isolated from the ext-rep. The guaranteed precision is explicitly
      given in all extended functions which use approximations.

The current schema definitions of extended functions:

    function_on_ksubsets_of_indices = element function_on_ksubsets_of_indices {
	attribute domain_base { "points" | "blocks" },
	attribute n { xsd:nonNegativeInteger },
	attribute k { xsd:nonNegativeInteger },
	attribute image_cardinality { xsd:nonNegativeInteger },
	attribute ordered { xsd:boolean },
	attribute precision { xsd:positiveInteger }? ,
	attribute title { text }? ,
	map
    }

    function_on_indices = element function_on_indices {
	attribute domain { "points" | "blocks" },
	attribute n { xsd:nonNegativeInteger },
	attribute image_cardinality { xsd:nonNegativeInteger },
	attribute ordered { xsd:boolean },
	attribute precision { xsd:positiveInteger }? ,
	attribute title { text }? ,
	map
    }

    map = element map { map_entry + }

    map_entry = element map_entry {
	( preimage | preimage_cardinality | blank )
	,
	element image { i | n | d | not_applicable }
    }

    preimage = element preimage {
	n +
	|
	element ksubset { n+ } +
	|
	entire_domain
    }

    preimage_cardinality = element preimage_cardinality { n }

    blank = element blank { empty }

    entire_domain = element entire_domain { empty }

I don't want to repeat here the entire semantics of extended functions,
since the fundamental part has not been changed. For details, please
refer to my first post. Here are some important new/cleared up details:

- *** In any extended function the images must be distinct. ***
  For functions, that means that the preimages are always maximal.

  For <function_on_indices> the <preimage> can contain only "n+" or
  <entire_domain>.

  For <function_on_ksubsets_of_indices> the <preimage> can contain
  only <ksubset>s or <entire_domain>.

- Quasi functions are extended functions with all preimages collapsed.
  Mixing collapsed and normal preimages are not allowed. [1]

- Functions must be "ordered", which means that their mapping part as a
  list of objects is required to be ordered by the preimages using the
  canonical ext-rep ordering (length, lexico-graphic). We call this
  "natural" order.

  Quasi functions can optionally preserve this natural order but they
  are not required to do so. However, implementors are encouraged to set
  up uniform "order friendly" policies within particular areas.

  To explicitly indicate the status of ordering, a new mandatory boolean
  attribute, "ordered", was introduced for <function_on...>s.

- When numerical approximations are used for images the "precision"
  attribute must be used in <function_on...>s explicitly stating the
  numerical precision in decimal digits. The Producer/Writer application
  is assumed to guarantee that the printed values are correct up to
  this precision.

  The Producer/Writer is required to generate an ext-rep document
  in which all images are distinct in terms of the printed
  approximations with the explicitly stated precision.

  Although extended functions within a document or across different
  documents can have various precisions, implementors are encouraged to
  set up uniform precision policies within particular areas.

- Implementors are encouraged to use the <info> fields to promote
  information which otherwise would be lost by numerical operations, by
  waived ordering, or just simply cannot be expressed in the outlined
  schema.

Notes:

[1] Now that we settled the order issue, I don't see anything against
    mixing original and collapsed preimages within a quasi function,
    assuming that we would require preserving natural order in this case.

--             ,
    Peter Dobcsanyi