[Os-project-managers] Fork in the Road

[Horand Gassmann]

Kipp Martin <kmartin at chicagobooth.edu> wrote:

>> This has one particular disadvantage: a local solve() is _different_
>> from a remote solve(). A local solve needs to be given an OSoL file (or
>> the <osol> element only), while the remote solve() needs the larger
>> version. This could be confusing.
>
> You have hit on the problem exactly!  We need to encapsulate. The  
> OSoL should be nothing more than solver options. The OSrL should be  
> nothing more than solver results. I think our big mistake was taking  
> elements from OSpL and putting them in OSrL/OSoL. I see no problem  
> with putting OSoL/OSrL inside OSpL. It actually makes a lot of sense.

> However, I do not think we should do any kind of element conversion,  
> i.e. changing the optimization tag to an osol tag. I really don't  
> like the idea of changing tag names if that is what you are  
> proposing. I think OSrL/OSoL should be what we had in 1.0 (of course  
> with the changes we have made to the optimization element) and we  
> put this inside OSpL.

I think we are constitutionally obligated to call the root element in  
an OSrL file <osrl> and similarly for <osol> in an OSoL file. It would  
be a mistake to do away entirely with the OSoL and OSrL schemas.

If we want to work with the idea of header and data, this then would  
look like this:

<osrl>
     <resultHeader>
         ... (the header information we currently have...
     </resultHeader>
     <resultData>
     ....
     </resultData>
</osrl>

The syntax of resultData would be exactly what we currently have in  
<optimization>. In fact, if you are opposed to renaming, we could keep  
<optimization> here, although I prefer to be pedantic and use the  
"data" designation. We are proposing such wholesale changes, anyway, a  
name change more or less isn't going to make a difference.

OSoL would be analogous. I am not going to write it out. And if  
packaged inside an OSpL file, we would have

<ospl>
     <processHeader>
     ...
     </processHeader>
     <processData>
         <general/>
         <system/>
         <service/>
         <job/>
         ...followed by an optional choice of
         <osol>     or    <osrl>
     </processData>
</ospl>

This represents a major change, as I said, but it is mostly moving  
around elements and renaming two of them. Most of the parser work can  
be reused, although we would need a proper OSpL parser, and I am not  
sure off-hand how one calls one parser from within another --- but  
these are details that we can work out, I am sure. The big picture is  
the important part, and the most important is the idea of nesting  
OSoL/OSrL inside of OSpL.

However,  consider this also: A user (or AML) does a local call to  
OSSolverServices. It gets back an OSrL file. Cool. Next time it does a  
remote call and gets back an OSpL file. Whoops, the format has  
changed!!! This can't be good! So it's fine to put OSoL inside of  
OSpL, but the return from either a local or a remote solve must be  
OSpL, and for a local solve the wrapper information must be generated,  
and it must be empty.


As for the potential impact of this on the paper, I actually believe  
it to be minor. But let's discuss the big picture first.

Cheers

gus