>>THe only problems that I saw are the following:
>>- Orbeline has a bug that prevents floats from working. We should comment
>>them out for now, and replace them with doubles.
>
>Ok. Done. This raises a question, though. Should there also be an
>Int type code? My copy of the model manipulation api does not list either
>Int or Double as valid type codes. Are there any others? I'll take a look
>at the application model today and see if it needs any other primitive
>types. Perhaps we can discuss this during the conference call
>this afternoon.
>
Int is not a CORBA type so it is not supported. I think double should be
supported, and probably is already.
>>- In most objects, all attributes are inherited via the is-like link. So,
>>most objects need
>> is_like inherits (attribute ...)
>
>Yes, my mistake. I should've known.
>
OK.
>>It turns out that in the presentation model most attributes are inherited.
>>I wonder if we could have another way of specifying inheritance something like
>>
>> is_like inherits_all_except (attribute ...)
>
>That would work. Alternatively I thought it might be nice to have some
>command line switches for the mrl parser that would cause it to spit out
>information about the ontology being translated. One such switch might be
>to list all attributes which are not inherited by any rule.
>Actually, the parser is pretty well split into a front end which builds
>an AST and a back end which generates code. We could conceivably make another
>back end which just performs analyses on the AST's (like above).
>
I would not invest more work in the parser. I would rather have
information commands be part of the Model Server, which, for example,
pretty print objects. The HTML generator, which generates the
documentation, will show all the info about each attribute, including
whether it is inherited or not.