Re: Syntax guidelines
Jayakumar Muthukumarasamy ([email protected])
Thu, 22 Dec 1994 19:31:58 -0500 (EST)
>
> Hi,
>
> Here are some guidelines for the model syntax.
>
> The files containing ascii versions of the model have extension mtf
> (Mastermind Text Format). We cannot use mif because that extension is
> already used by framemaker.
>
> - Each object is defined within {}.
> - The first word after the { is the name of the interface in IDL.
> - After the name come attribute value pairs
> . The name of the attribute should be the same as the name in the model (IDL)
> . Attributes that have collection values have the values enclodes in ()
> . If an attribute has a collection as a value, and the add method is called
> add_xxx,
> then the name of the attribute in the syntax should be xxx
> - Each object has a unique ID in the syntax file, so that it can be
> refered to by other obejcts. References use the syntactic marker @
> (sse example of grids below).
> . I am assuming that the program that saves models to files assigns ID
> numbers to all internal objects that need to be saved in a file.
>
> Open issues.
> - How to refer to object defined in other files.
> One possibility is as follows:
> - Top level objects can have a name attribute.
> - Top level objects can be refered to with @name-of-object (see
> example with button below).
>
> Here is an example.
>
> {Template
> ID 1000
> guides
> (
> {Guide
> ID 1001
> direction VERTICAL
> position 50
> margin-1 4
> margin-2 3}
> {Guide
> ID 1002
> direction VERTICAL
> position 290
> margin-1 0
> margin-2 6}
> )
> grids
> (
> {Grid
> direction HORIZONTAL
> stretchable FALSE
> distance 50
> start @1001
> end @1002}
> )
> parts
> (
> {Template
> ID 1003}
> {Template
> ID 1004}
> {@button
> }
> )}
>
> I think all model components can be written out in a syntax like this one. It
> is a bit verbose, but easy to understand, easy to parse and easy to generate.
>
> 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.
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.
-jk