[sc34wg3] Comments on latest TMRM draft

[Robert Barta]

On Thu, Jul 14, 2005 at 08:52:58PM +0200, Lars Marius Garshol wrote:
> Rather than respond to other people's comments all the time I figured
> I would try writing some comments of my own for once. :-)

Just as a clarification from my side:

  - whatever the editors of TMRM have put into their draft was _their_ choice :-)

  - I did my best to explain the reasoning between the various choices of

       http://astma.it.bond.edu.au/junk/taup-model.pdf

    to them.

So the following comments are all relative to Tau+ (and not TMRM).

---

> On the identity of proxies: the difficulty here is that in mathematics
> there is no way to distinguish between two proxies whose values are
> equal.

Sets which are identical, are identical. So there is no problem with
that.  Something which is not so obvious in Tau+ is 'equivalence' that
is induced by \bowtie and by that alone.

> However, the TMDM representation done in the TMRA '05 paper by
> Barta and Heuer seems to get into difficulties because of this rule.

No comment.

> The proxies defined using the set of natural numbers seems very
> misplaced. Firstly, it redefines semantics defined in TMDM.

What a shock! And it even does that formally! :-)

Seriously, this has to do with introducing some predefined stuff to
bootstrap the whole machinery. The choice using natural numbers is
completely arbitrary, we could have used colors as well. Anyway,
_something_ has to be used as distinguishing values to define these 4
thingies.

> Secondly, it does not seem to serve any obvious purpose. Thirdly,
> the definitions seem grotesquely distorted. Suggest that this be cut
> altogether.

You could omit that entirely, but then we would not have any
subclassing, instance-ing. Not much fun.

> Why cannot keys occur more than once in a property, and why is this
> constraint first introduced in the definition of the function keys(x)?
> This constraint seems likely to cause difficulties further down the
> road. Even if keys *did* occur more than once, the result would still
> be a set.

That was caused by a typo in an earlier Tau+ version. Keys, of course,
can appear any number of times inside one proxy. [ Very alert reading! ].

> Why does values(x) produce a bag? And shouldn't the definition use
> some other formalism to indicate that it produces a bag?

In the proxy

  { < name, "Lars" >, < name, "Larsbot" >, < nickname, "Larsbot" > }

then values (x) gives

  { "Lars", "Larsbot", "Larsbot" }

I do not think it is clever to convert this to the set, because it
would actually delete information that the value appears twice.

> The proxy merge view function should surely be defined on a map
> rather than a proxy, given that proxies will occur as values in
> other proxies?

There are two things:

  - the \bowtie, a function on two proxies

  - applying this \bowtie to a map

The first defines the view, the latter actually produces it.

> --- 3, 4, and 5
> 
> The purpose of these clauses is not clear. Some clarification would be
> welcome.

In my background discussions with Patrick my line of reasoning was
that if TMRM is supposed to become a fundamental model, then

  (a) it needs a machinery to allow to define how it relates with TMDM
      (since TMDM does not define such a machinery),

  (b) it needs a machinery to allow to define its own disclosure
      concept properly,

  (c) and if the machinery is there, why not use it for TMQL, TMCL, whatever.

Obviously the editors followed me here and at the moment I lack vision
of a better place for this. Inarguably, it needs a fair bit of more
prose (and examples) to demonstrate that the formalism is actually
quite trivial if it is going to stay in TMRM.

\rho