Re: call for comments on publishing task models spec

On 18/07/12 12:03, Gaelle Calvary wrote:
> Dear colleagues,
> 
> Please find few comments and/or suggestions below:

Thanks for the feedback. I have updated the draft on editorial points,
but leave substantive changes to further discussion until we have
reached a rough consensus.

> 0- General comments
> a) the document is ambiguous. It has to make clear whether the task
> metamodel that is described (section 3.4, typically Figure 1) is pure
> CTT or the W3C Task metamodel. We should name it to remove this ambiguity.

I checked with Fabio, and he confirms that the W3C specification will
define an updated version of CTT.

> b) everywhere, change "application" with "interactive system"

Okay, but note that most readers of this specification will be thinking
in terms of web applications. I've added a paragraph to the start of the
introduction to make it clear that we're covering a wide range of
interactive systems from microwave ovens to web applications.

> 1- Abstract
> Task models are useful when designing, developing, executing and
> evaluating interactive systems

I don't think we have a consensus that CTT is intended for executing
interactive systems. My understanding is that CTT is aimed at providing
a level of description suitable for review, but without the full details
as would be needed to control the user interface. In other words, CTT is
not supposed to be a programming language.

> 2- Specific requirements for task meta-model
> 
> In this section there are some requirements that have been specifically
> identified for task models.
> 
> Req1: Separation of static aspects from dynamic aspects
> Req2: Separation of the hierarchical structure from other aspects
> Req3: Possibility of relating task performance to the context of use
> (even if modelling the context of use is not in the scope of this document)
> Req4: Provide an initial taxonomy of task types (optional usage)
> a) The relevence of the requirements must be justified
> 
> b) Are these requirements satisfied by the task M2 described in 3.4?
> 
> c) To which extent are these requierements specific to Task M2 (see for
> instance Req1)?

I leave it to ISTI to answer these questions, but my sense is that the
requirements aren't normative, and rather intended to give the reader a
sense of the assumptions that underlay the CTT notation.

> j) UML class digram:
> 
> - Nary-operator should include only one type attribute whose value could
> be "choice" OR "interleaving" OR etc. As currently expressed, the Nary
> operator can be BOTH choice AND interleaving AND etc.

I am not an UML expert, what change is needed to the diagram?

> - Task subclasses: the predef_type should belong to the Task abstract
> class so that to make it possible to define types of abstraction tasks.
> Types enumerations should also be provided
> 
> - Task decomposition: 2..* -> + ordered + 0..* . Otherwise the tree has
> no leaf nodes.
> 
> - Task: In order to increase the exprressive power of the metamodel and
> to better cover UI plasticity, we suggest to move Frequency and
> Context_of_Use as attributes of 1-aryOperator, and to change the
> cardinality from 0..1 to 0..*. By doing so, it is possible to specify
> that a task is frequent on PC, but not on PDA. Similarly, we can express
> that it is optional on PDA, and not on PC.
> 
> - ext-type could perhaps be added as an attribute for 1-aryOperator and
> N-aryOperator.
> 
> - As discussed previously, the notion of Actor in charge of executing
> the task should be modeled as an attribute of the 1-ary Operator so that
> to easily support the dynamic migration of tasks execution between human
> and system.
> 
> - The Condition part (ConditionGroup, BinaryOperator, ConditionLitteral)
> is not clear (and is not described in the text). Would it be possible to
> clarify the nature of the BinaryOperator (type attribute missing)? It is
> also unclear whether ConditionLitteral are elementary.

We can discuss these in tomorrow's call and see if we have a rough
consensus on what if anything we need to change in the specification.

Best regards,
-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Wednesday, 18 July 2012 12:14:32 UTC