The following are some notes on the subject that need to be scenarioized.

During the course of diagram editing, the following kinds of invalid conditions can be created. Probably most predominantly the signature of a node is changed such that uses of the operation in some place other than where it's changed go invalid. From a dfd editing perspective, the rule is that changing the signature of a node in any diagram changes the fmsl definition of that op's signature. So this means is that we can change an op's signature from more than one place in a multi-canvas dfd. The underlying op definition is that which corresponds to the most recently changed dfd.

Another kind of invalidation may happen when a node or edge name is changed. What we might do to prevent this (perhaps totally) is to disallow changing the name of a node to an existing node with a different signature than that shown in the dfd.

I don't know right this minute if there are other ways dfd editing can invalidate the underlying spec. I'm not (really) falling off here, it's just that it's kind of late and can't think through clearly what other kinds of spec-invalidating things can happen during dfd editing.

When we run Tools->Validate, we just let the chips fly where they may. Specifically, we have op defs that correspond to the most recent dfd edits. If an op is used inconsistently in more than one place (within the normal scoping rules of fmsl), then the checker detects the error in the normal way.

What we now have to come up with is the way fmsl checking errors are displayed in the dfds. Here's a crack at the invalid cases that arise, where we care from the dfd perspective:

1. An fmsl dataflow attribute fails to type check in some node; in this case, we color the edge(s) that correspond to the type-incorrect df connections in the fmsl
2. We should probably display in some way type checking errors that do not directly correspond to dataflow, because if we have a type-correct spec to start with, we need to let the user know when df editing changes cause problems. For starters, we might just make the display textual, with the general indication an error condition shown in the dfd display by coloring the affected node(s) or edge(s) red.

We do indeed need to deal with the case where we load a spec that is initially invalid. I think we should handle it in pretty much the same way as the docgen tool. Specifically:

1. we can't load a spec with any syntax errors; i.e., after the load discovers one or more syntax errors, it pops up a dialog says the spec cannot be loaded; if we're running stand-alone, there can be an `Show Errors' button in the error dialog, that when pressed displays a textual listing of the error messages; in stand-alone mode, there can also be a message that says to use an fmsl editor (IDE) to fix the errors
2. if the spec has type checking errors, we also pop up a dialog, with buttons

   ( Proceed with Load )     ( Cancel Load )     ( Show Errors ... )
   

   If the user chooses "Proceed with Load", a second warning dialog will pop up explaining that validation will continue to fail, unless (somehow) dfd editing fixes the entering errors.
3. If the spec checks fine, then everything's hunky dory for the load, and we can display a "load successful" message if we care to.