[RIF] Extensible Design Conditional Language

This note is to clarify my marks made in the telephone conference regarding
the proposed language.  I wanted to raise two cautionary flags:  
 
1)  I would like to see us determine the information requirements and
objects involved in the language before moving too quickly on to any
specific user oriented syntax.  I no doubt missed something crucial, but the
proposal seemed to be coming at this from the other direction.  Basically, I
want to have an understanding of the objects involved and an overview before
trying to map this to a user friendly language and I would like to see us
try and spell that out.
 
For example, what kinds of objects are involved and how are they related?
I'd like to see an inventory with examples of each.
 
    expressions, boolean functions, arguments, named arguments,  data,
datatypes, variables, function application  and also addressing bindings,
scope  ???
 
I do recognize and appreciate that an early user friendly syntax is helpful
to provide readable examples for discussion.  I am just uneasy starting
there and then mapping it to XML.    
 
2)  We will need to make some careful choices about our requirements for the
XML syntax.  For example, to extend the current examples as proposed, a
consequence of the current approach would be that there are multiple
schemas.    This can be good or bad depending on whether the extensions tend
to focus more on additions (or minor changes) to a few functions,  or choice
of a language.
 
People rightly pointed out that the schemas can be extended by
substitutions, and that the schemas provide explicit definitions of the
variants, 
but there may be a whole algebra of types involved (lets describe it first
before choosing an implementation), and we need to examine how the
variations actually occur in practice.
 
For example, an approach that works well when the variations are realized
primarily by tweaking the capabilities of individual operators might be  to
provide a static schema, spelling out a the basic syntactical structure
capturing 1) (and including a mechanism for extensions.) Wth this approach,
the  variants of the language constructs are identified by the attribute
values and/or element values of standard constructs. 
 
    <apply>
       <operator name="exists"  definition="URIDefOfExists"/>  <!--
operatior -->
       <bvars>   <!-- bound variables -->
            <var name="buyer"/>
       </vars>
        ... expression ...
    </apply>
     
These remarks should NOT be taken as a complaint about the extremely helpful
contribution that this proposal has made to the process.  Nor should it be
construed as having taken a position on most of these points.  I just want
to make sure that we are aware of some of the other options that are
available at this level and some of the consequences of one approach versus
another and am already thinking about how to cast the specific examples in
some of this framework.
      
 
Thanks.
 
Stan Devitt