>
>>
>> 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 {...}
> }
> )
> }
What if we need to refer to the task
...
{Task
is-a click-button
preconditions {...}
}
...
in say the presentation model. How is this going to be accomplished?
I guess, the reference @TASK.CLICK-BUTTON was introduced for exactly this
purpose. This is ok for users to reference other tasks. But, I feel it
would be better to have "tags" for each task that the user wants to
reference. This is similar to named & unnamed structures in C. If the
structure is unnamed, it can only be used where it is defined. But
named structures can be used elsewhere using its name. Hence if the user
wants to reference a task someplace else, then the task should have a tag.
Although it needs more work on the part of the user, I think it is good.
So, for tasks that will not be referenced elsewhere, no tags need to be
defined.
This is different from UIDE as follows. In UIDE the above hierarchy
would have been defined as follows.
Task: some-name-for-task
{
Subtasks: click-button
Preconditions: ...
Effects: ...
}
Task-Subtask: some-name-for-task click-button
{
/* initialize parameters here for click-button here */
}
The task click-button is assumed to have been predefined in the
library. All preconditions etc will have been defined in the library. Any
task that alters the precondition is actually a different task. So we don't
have the "is-a" relationship defined above. To be frank we didn't have
much problems with this approach either, since the click-button task
was sufficiently parameterized. i.e. the preconditions were expressed in
terms of variables which were defined later. But, the important point is
that we needed someform of "ids" or "tags" for every task, just to be able
to build the hierarchy.
The advantage with the UIDE approach is that the number
of levels of nesting is not much. I do not know which way we want to
follow. It would be unfair on our part to talk decisively about this,
because Noi has been working on this and I am sure she has some ideas
about this on her mind.
But, one point to be aware of here, is that the "id" that the
user uses in the language needn't be the same that the system uses
internally. We had confused the two in UIDE and ran into some problems.
>
>> 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).
>
I have a feeling there will be a lot of braces ("{}") for even
moderately big hierarchies and that could be a problem. But, I think we
should see what Noi & Spencer have to say regarding this. Opinions?
-jk