Thanks for your comments.
>
> Pedro,
>
> Couple of issues here. Having IDs for objects is good. We had
> problems not having it in UIDE. But, is it necessary to expose it to
> the user? It would be a nightmare if we have a lot of objects, and
> when they are cross referenced. I am thinking about the task model at this
> point. Since we need to specify the relationships between the tasks,
> this scheme will soon become a burden for even non-trivial task trees. On the
> other hand, we can let the system generate ids internally, when the models are
> interpreted or compiled. The reason for this is ease of programming, and
> efficiency. But, the user still needs to be able to cross reference objects,
> and some form of ID is required. Object names may not be suitable for this
> for the following reason. When an interaction technique
> "click-using-left-button" is attached to several tasks, we have many
> tasks (instances) with the same name. How do we distinguish one instance
> from the other? We should find other means to solve this problem.
>
You make a couple of points here.
I think you are agreeing that we need some kind of ID. Since I wrote the
message I was thinking that we should call IDs "tags", and allow symbolic tags
(strings).
I was envisioning that the namespace for tags is a object declared at top
level. The idea of tags is to allow internal objects to refer to other
internal objects. Symbolic tags are nice when humans are writing the specs.
When a model is created with an interactive tool, and dumped to a file, the
tags would be either numbers of strings of the forms TASK-1245. I would also
require the interactive development tools to preserve symbolic tags that the
developer might have used when defining the model in a file with a text editor.
References to other top level objects (eg library objects) is done using a
name. We need to come up with a naming scheme, and a syntax to refer to names
(eg @TASK.CLICK-BUTTON, so it looks like a tag, but since it has a "." it is a
top level object).
I am a bit confused by your example of
> "click-using-left-button" is attached to several tasks,
because you said there would be several instances when the task is attached to
multiple other tasks. In fact there would be several "specializations" of the
"click-mouse-button" task. Each specialization would differ from
"click-mouse-button" in some attributes such as preconditions, effects, which
button, etc. I don't see a problem with references here. The spec would look
something like:
{Task
sub-tasks
(
{Task
is-a click-button
preconditions {...}
}
)
}
> The syntax above looks very similar to s-expressions. The tricky
> thing about s-expressions is that there are too many levels of nesting.
> It is easy to change the meaning of statement just by placing a parenthesis
> in the wrong place. Moreover, we will be using "text" to enter the models
> very heavily, so it is better to have a syntax that is very readable.
> Otherwise, we may spend a lot of time debugging models. Moreover, it is
> conceivable, that some parts of the model may have to be done textually
> just because it might be impossible to do it using tools. So, we probably
> want the syntax to be very readable. With lex/yacc it should be no problem
> parsing the models even if they are somewhat complicated.
>
I agree 200% that we need to make the syntax readable because a lot of model
entry is going to be done using a text editor. It will be sometime before we
have interactive tools to do this: we need to specify the models for the
itneractive tools using the textual syntax to bootstrap our tools.
The idea behind the syntax I proposed is that it is quite readable, and easy
to extend. Adding new attributes to the model doesn't cause you to have to
update files containing models.
I agree that there are lots of levels of nesting, but I think that is
intrinsic in the models we are defining. I don't regard the syntax as
parenthesis heavy: there are only parenthesis to define multi-value
attributes, and to define whole objects (if this was Lisp, there would be
parenthesis for each atrribute value pair).
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/823-6714
URL: http://www.isi.edu/isd/HUMANOID-HOME.html