- 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>
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