[kepler-dev] how (backward-)compatible are MOML files across versions

[Bertram Ludaescher]

Hi:

I have a question, possibly mostly to the Ptolemites among the
Keplerites:

If I create a workflow/model and save it as a MOML file and it runs on 
my Kepler version as of today, how can I know whether this file works
with a previous Kepler release or with a future one.

I noticed that MOML files are not "self-contained" and refer to Java
classes etc. If one views MOML as the Kepler/Ptolemy "internal"
language (working with a particular Kepler/Ptolemy build), then what
does an "exchange" language look like.

For example, if I have a web-services only based workflow, then it
should run back and forth the Kepler release history (as long as the
web services defined in it remain valid).

So overall what I think we need is a more self-contained an explict
format to "archive" workflows. Among the things to be added would be 
"imports" or "uses" statements in the header so that dependencies on
external tools and services would become explict.

Thinking a bit further, in the web services setting at least, but
maybe beyond, one would could think of a "binding mechanism" so that a 
workflow mentions a remote service S of a particular type, say
	S :: highway_number --> traffic_info
(S returns current traffic info, given a highway number)
but the actual  WSDL or location of the service is a parameter that is 
only bound later...

Bertram