Notes:

• The text editor windows are file-oriented, in that there are separate non-modal windows for each file of the DFD.
• When the user selects `Elements->Source Text', the dftool displays the file containing the FMSL definition of the operation of the current canvas.
• There will be rules for the default creation of files if no fmsl files exist prior to the first File->Save operation.
• Fancy forms of text editing will be part of the Eclipse plug-in; in the stand- alone version, just simple text editing will be fine, with perhaps an option setting that allows the user to choose which text editor to use.

Here is the precise correspondence between fmsl source text and dfd:

DFD	FMSL
node	operation, which must be the component of another op unless it's the level 0 node
level	operation, with components and dataflow attribute
edge	a connection element in a dataflow attribute spec, plus a obj declaration of the same name as the edge name
data store	value declaration of the same name as the data store name

We need to do something in the realm of context diagrams, since in fmsl we can't have a dfd just sitting around without an outermost op to contain it. So, I think we need to do something like have each canvas always be a level, with an appropriate name, say in the canvas window banner.

To deal further with the context issue, we need to require that each df canvas corresponds to a unique op definition. This is related to the "inny" versus "outty" in the semi- and fully-formal chapters of the book. The important point is that each dfd canvas has to be defined in terms of an op with components that are effectively refs to other ops, so that the same op can appear in two or more dfd contexts. As it is now, I'm pretty confident that the outty-style notation makes this happen. So, again, what needs to happen in the dftool is that each canvas correspond to a unique op def. We can use overloading and module qualification to deal with two or more canvases having the same name. It may be appropriate, as an option or required, to put the fully qualified, and if necessary signature, in the window banner. The "if necessary" part for the signature can mean that the signature is not necessary if the op is not overloaded in the current module context. And then we have to be clear about how module context is reflected in the dfd display. Here's a crack:

• we load up a spec to get all of the modules and other defs
• we qualify an op name in the window banner in the same way as we do in the data dict, viz., we use the "in module X" form of disambiguation
• we can also use the same form of op overload disambiguation as we do in the data dict (if there is any), or we can do what we said just above, i.e., disambiguate the op name in the dfd canvas banner with its signature if its overloaded in the module scope in which it's defined
• to keep things intuitive for simple dfds, we use the same default-main module convention when we haven't loaded any fmsl into the dftool; in this way, we won't have any module disambiguation at all in canvas window banners, signature disambiguation only when necessary, and disallow two canvases with the same name and signature
• to handle the latter disallow case, we need to figure out at exactly what point the disallowance occurs; I think I'd very much like to opt for it to happen at explicit validation time, rather than having some fancy incremental checking that detects it when, say, an input or output is added or deleted to the diagram

Editing text potentially invalidates dataflow, but this is detected in the normal way in the text. I.e., errors occur when dataflow connections are type checked. What we need to come up with is the appropriate (aka, clear and helpful) way to display type checking errors related to dataflow in the dfd itself. It may be some variant of the roll-over displays for edge connection. E.g., when there's a type mismatch in any df connection, the edge(s) in the dfd that correspond to that connection are colored red.