[Os-project-managers] Fork in the Road

[Kipp Martin]

Hi Gus:

> 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.

Absolutely! I totally agree! Perhaps I miscommunicated. I want OSrL to 
be the solver result and OSoL to the solver options. I want to PUT BACK 
into OSpL what we took out. So for example, I do not want OSoL to have a 
tag <solverToInvoke>.  I do not want OSrL with elements for things like 
<totalJobsSoFar> -- that is system stuff and goes back into OSpL. I want 
OSoL and OSrL for the what they were first intended.
>
> 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...

Here is where we differ -- if we put in the information we currently 
have we have the same old, same old problem, namely some information is 
for the solver server and some is for the solver.  Here is what I am 
objecting to so strongly -- having either OSoL or OSrL with tags that 
get read by BOTH the solver server and the solver.
> </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.

Yes, I agree with this.
>
> 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.

Why can't the remote server just return OSrL? Why does it have to be 
symmetric. That is, why can't you send OSpL remotely and get back just OSrL?
>
>
> 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


>
> Cheers
>
> gus
>


-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS

Sent without Blackberry, Droid, iPhone, or any other
wireless device.
--