Re: AUIHomeFinderCaseStudy (public-mbui@w3.org)

 Thank you Davide and Carmen for stating your point of view.

Rather than punctual comments on the file, I would like to sum up here what
seems to me to be the point of difference, a philosophical one, I should
say.

Citing from the beginning of the document MBUI - Abstract User Interface
Models, I read

The *Abstract User Interface* (AUI) (corresponding to the
Platform-Independent Model –PIM– in MDE) is an expression of the UI in
terms of interaction units without making any reference to implementation
both in terms of interaction modalities and in terms of computing platform.

and

An AUI could be connected upwards to a task model and/or downwards to one
or many Concrete User Interface Models. This connection could be achieved
via different mechanisms, such as mapping, transformation either at
design-time or at run-time.

In your comments I see a rather specific way of defining this upwards
relation, where the elements in the AUI are only there to allow the
execution of tasks. I rather see them as ways of logically organising the
information needed to perform the task as well as the support for their
execution, without necessarily being in any specific relation with them.
The relation would be given by the transformation, mapping, etc.

For example, a spreadsheet could support a number of tasks, while a complex
interface such as the one in the case study basically supports only one.
So, the difference between abstract and concrete UI models, to me is not a
difference between WHAT and HOW, but between platform and modality
independent vs dependent.

In this sense, the tree I drew was to be meant as a lower limit. I agree
that one could stop at any level above the ones I put there, but my
intention was that one should not go further. In any case, it is undeniable
that defining a range means defining a minimum and a maximum, so even at
the abstract level one might require that the interface provides ways to
receive these. Even the example where one writes a string "From X to Y"
(and the system parses it) would in any case be an example of this, as X
and Y are two different place-holders for those specific roles, whereas
writing a string "Range centered in Z of size W" would not.

So, if one stops the modeling at distASelector, both solutions are
acceptable, whereas if one distinguishes minDistASelector and
minDistASelector then only the first is. I think that a language should not
force one in either way, as it is the decision of the designer up to which
point the AUI must compel the CUI. To reiterate, to me the AUI is a way of
specifying units of interactions, based on some logical connection which
can then be related to the task model, not units with specific tasks.
Otherwise, why could we not have a direct relation between the task model
and the CUI?

But now, there is the second philosophical point, concerning the whole
enterprise. If we are going to define a metamodel, I think this means that
this must represent a common interchange language in which to express
different languages. This is an important question to understand if we are
having a metamodeling approach, or we are defining a standard language. In
the metamodeling approach, instances of AbstractInteractionUnits are not
specific elements, but types with which to model the abstract interaction.
So, for example in UML, the class WorkingGroup (which is part of the W3C
model) is an instance of the class Class (which is part of the UML
metamodel) and MBUI is an instance of WorkingGroup. If this is the way we
intend to proceed, then I would say that we have to be as liberal as
possible in leaving languages to realise the notion of AIU, and not commit
to any specific modeling discipline, except that represented by having this
collection of models. If we intend to define a language, then I think this
has to be discussed in much more detail.

It might be that I completely misunderstood what you have in mind, in which
case, I would be happy to revise my understanding
best

paolo