A case against standards

[Ilmari Heikkinen]

Hello Armin, and thanks for the reply,

> There is a reason why these individual conversion tools have a big number of
> options: because only in simple cases can you just talk about "convert this to
> that". In general you want more control about the process. I tried to express
> this point e.g. in the section about equality: conversion is not an absolute
> notion. (This is something I discovered while playing with the construction of
> such a meta-converter tool as well :-)

Wouldn't it be that conversion tools have a big number of options
because they have the ability to do several different conversions?
Passing more input data to the converter specifies the end result more,
which I don't see in itself as something that nullifies the ability to
talk about converting A to B.

In particular, is there something that can't be expressed as a
conversion from one state to another? Regarding the equality, I might
express the comparison between two images projected to the object set
with the notation ((image->object),(image->object))->(equal?)  

If there is need for finegrained control over the process, then the
endpoint is not specified, which moves the specification problem to the
subconversions of the big conversion - defining the endpoint as the set
of actions it takes to get there. Or how do you see it?


Sorry if I come across as inquisitive/ignorant, but I'd like to find out
the limits of the system. Easier to correct my errors and fallacies in
design and thinking early on :)


-Ilmari