- From: Stan Devitt <stan.devitt@gwi-ag.com>
- Date: Wed, 26 Apr 2006 10:04:50 +0200
- To: "'public-rif-wg@w3.org'" <public-rif-wg@w3.org>
- Message-ID: <1512B5F2ED998C4BB3E2688B8EBEDB79997E9A@mxex-tr-01.gwi-ag.com>
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
Received on Wednesday, 26 April 2006 08:05:03 UTC