Re: call for comments on publishing task models spec

Hi everybody.

Thanks Dave and the CTT group for putting this together.

Here are my comments.

Concerning operators.

Interleaving (T1 ||| T2 ||| … TN): The connected tasks can be
performed concurrently, without any specific constraint.
Order independence (T1|=|T2 |=| … TN): the tasks can be performed in any order;
Synchronisation (T1|[]|T2 |[]| … TN): The tasks are synchronised each other;
Parallelism (T1||T2 || … TN): The tasks are performed in true paralllelism.

I think that the semantics should be a bit more precise, with respect
to Task decomposition.

As I would intend it, from the names

Interleaving would meanthat any subtask of any task can be performed
at any step,
Order independence would mean that any task can be started when no
other task is running, but no other task can be started once one has
started until that one is finished
Synchronisation would mean that each task must advance one step at the
same time. This opens the problem whether all tasks must execute the
same number of subtasks or some can end before the others.
Parallelism would mean that any subset of subtasks from any task can
be performed at each step.


In all cases, the whole task is completed when all subtasks are completed.

Is this the intended meaning?

Are disabling, enabling and suspend-resume? It seems to me that a
reasonable semantics can be given only for the binary case. Then,
notationally, one could also indicate a chain of disabling, enabling,
etc. But if we consider them as n-ary, without imposing an order, it
is not clear what is enabling what, as I do not see a natural notion
of distribution for these operators). If we are imposing an order, are
we saying that T1>>T2>> … TN means that T1 enables T2 which enables
.... which enables TN, or that T1 enables the fact that T2 enables ...
that enables the fact that TN-1 enables TN. I guess the intended
meaning is the first, which is however a chaining of binary relations.
(This is different from the previous set of operators, which are
naturally distributive)

I am not sure we really need the user and abstraction tasks type. How
are we checking that the user is planning or doing some
problem-solving? From the operational view, we can only specify the
system and the interaction activities.

Concerning the definition of ConditionLiteral, I am not very happy
with the fact that it has two attributes, only one of which is to be
used at each time? Why not use ValueSpecification from the UML2
metamodel, which can then be a LiteralSpecification, an Expression, an
InstanceValue (for reference types) or even an OpaqueExpression
(written in some executable language). This is what actually happens
in UML2 when one expresses constraints by providing
ValueSpecifications.

talk to you tomorrow!!

best
paolo

2012/7/16 Dave Raggett <dsr@w3.org>:
> This is a call for comments on publishing the following document as a
> First Public Working Draft:
>
>   http://www.w3.org/2011/mbui/drafts/task-models/
>
> My aim is to ask for a formal resolution in this week's MBUI telecon to
> publish the document.
>
> p.s. this was derived from the Google Doc, although it took quite a bit
> of work!
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
>



-- 
Paolo Bottoni

Associate Professor of Computer Science

Email: bottoni@di.uniroma1.it

Website: http://w3.uniroma1.it/dipinfo/scheda_docente.asp?cognome=Bottoni&nome=Paolo

Phone: +39 06 49918426

Fax: + 39 06 8541842



Important conferences:

http://www.etaps.org/

http://www.diagrams-conference.org/2012/

http://vlhcc2012.di.unisa.it/

http://www.informatik.uni-bremen.de/icgt2012/

http://www.dsmforum.org/events/GMLD12/

Received on Wednesday, 18 July 2012 22:35:48 UTC