[Os-project-managers] Schema changes

[Horand Gassmann]

Hi Jun,

Kipp and I had a one-hour meeting today. I was going to write up what  
we agreed on, but then I realized that our idea actually runs counter  
to what currently is in the schema, so a bit of rewording is in order.  
(Sorry you missed the meeting. We obviously could have used your input  
today! Hope everything is OK.)

Our first decision was to add a module OSrL2AmplSol. Purpose of this  
module is to take the task of writing the AMPL solution file out of  
OSAmplClient, so that we can call it from several places (such as a  
unit test), and to add capability to the interface so that  
array-valued results can be transferred back to AMPL correctly.

The second item we discussed was changes to the OSoL and OSrL schemas,  
along the lines that I suggested in the possible agenda item 1:

>> 1. Schema questions
>>   a. Should we have a "type" attribute in the <otherVariableOptions>
>>      element in OSrL?
>>   b. Should the type attribute be a string or an enumeration?
>>   c. If the latter, what should be the members of that enumeration?
>>   d. In both OSoL and OSrL, our <other> elements can have a "value"
>>      attribute, a <var> (or <con> or <obj>) array and an <enumeration>.
>>      Should these three options be mutually exclusive?
>>   e. If not mutually exclusive, do we need additional attributes
>>      "varType" and "enumType"?
>>   f. Should the attributes in e. be strings or enumerations? (Should
>>      this be the same for OSoL and OSrL?)
>>   g. If enumerations, what should be the members?

We agreed that a "type" attribute is necessary for OSrL and that it  
should be a general string, in symmetry with OSoL. However, in regard  
to item d. above, we did not realize that <var> and <enumeration>  
currently _are_ mutually exclusive (they are contained within a choice  
group), and so we recommended that --- to allow for full flexibility  
---- the user should be given the option of simultaneously specifying  
three different content options: A "value" attribute and a <var> array  
and an <enumeration> array>. This necessitated three separate  
attributes to describe the type of the option: "type" for the value  
attribute (since "valueType" would not be backwards compatible),  
"varType" for the values in the <var array>, and "enumType" for values  
in the <enumeration> array.

However, since this approach is not viable, more discussion is needed.  
Jun, you said that today you would know more about the feasibility of  
a meeting next week. Any developments, or should I just wait until you  
tell me you're back in the States? Again, hope everything is OK.

Incidentally, do you agree with our resolution of 1.a, b and c? If so,  
then I would make the changes to the schema and the parser, and then  
commit.

Cheers

gus

-------------------------------------------------------

Horand I. Gassmann, Professor

School of Business Administration, Dalhousie University
6100 University Avenue, PO Box 15000
Halifax, Nova Scotia, Canada, B3H 4R2
ph. (902) 494-1844
fax (902) 494-1107

http://myweb.dal.ca/gassmann/