W3C home > Mailing lists > Public > public-mbui@w3.org > October 2012

RE: Data interaction units, localisation and domain models

From: Jean Vanderdonckt <jean.vanderdonckt@uclouvain.be>
Date: Mon, 8 Oct 2012 11:07:06 +0200
To: "'Heiko Braun'" <ike.braun@googlemail.com>, <public-mbui@w3.org>
Message-ID: <005501cda534$4a890ab0$df9b2010$@uclouvain.be>
Dear Heiko,

Thank you very much for your comments. Please find below some further
explanation.
For your information, it is expected that a first complete draft will be
produced and freezed one week before the TPAC meeting in Lyon. All comments
are welcome on this version.

All the best,
Jean

Prof. Jean Vanderdonckt
Louvain School of Management (LSM)
Université catholique de Louvain (UCL)
 
Place des Doyens, 1
B-1348 Louvain-la-Neuve (Belgium)
E-mail: jean.vanderdonckt@uclouvain.be


-----Original Message-----
From: Heiko Braun [mailto:ike.braun@googlemail.com] 
Sent: lundi 8 octobre 2012 09:26
To: public-mbui@w3.org
Subject: Data interaction units, localisation and domain models

	
I am currently reading through the most recent AUI document. Some questions
came to my mind. Please bare with me if these have been answered elsewhere
already, but I am currently trying to catch up with the available material.


AbstractInputOutputData

- dataType vs. dataFormat: "type" seems to be a data field type, whereas
"format" sounds like a  document type description. Aren't these mutual
exclusive?
[[Jean:]] "type" indeed refers to the data type to be manipulated by the
AbstractIU. "format" (that is optional) refers to the input/output mask or
filter.

- dataLength & isDynamic: I am wondering if these attributes belong to the
abstract level at all. Assuming that any mapping between the domain model
and data interaction units belongs into the CUI, then I expect these at the
CUI level as well. 
[[Jean:]] First, keep in mind that the AUI per so should be expressive
enough in itself. Nobody can force to find additional information in a
subsequent layer (e.g., CUI) to find out missing information because we
cannot force anyone to go through all levels.
These two attributes describe the data subject to input/output in the
AbstractIU. This interaction unit could be (but not necessarily) be linked
to a domain model (through a domain reference). For instance, one can ask to
input/output/select information item that do not belong to the domain. For
instance, user's opinion, decision.

- mapping domain objects: Is a simple domain object reference is sufficient?
Does a more fine grained description of "what" should be mapped make sense
here? I.e. domain attribute keys? 
[[Jean:]] For the moment, we keep it simple deliberately. In the past, we
considered different types of mappings, including linking, binding, etc. But
we feel that this should be described more in the mapping between the AUI
and the domain, not in the AUI itself.

AbstractLocalization

Regarding the question wether or not this is an abstract concept. I can see
Jean's point: It requires a reference on the AUI level to map concrete
localisation concepts on higher levels. This question seems to be similar to
the mapping of domain objects. 

[[Jean:]] If we stick to the definition that a AUI should specify a UI
independently of any interaction modality, target platform, any context,
then the answer is yes: the AUI should not contain any reference to
localization, apart perhaps from its capability to be localized. When the
context of use comes into play, an AUI could be then refined depending on a
context, but it is no longer the same.

Which relationships to the domain model are needed and how are they
expressed? At what levels (AUI/CUI)?
[[Jean:]] Such a mapping could exist between AUI and domain, as well as
between CUI and domain.

All the best,
Jean



Regards, Heiko
Received on Monday, 8 October 2012 09:06:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:24:17 UTC