|
Difference between
version 14
and
version 13:
| Lines 44-45 were replaced by lines 44-62 |
| - * What should the interface look like for validating connections? |
| - * Architecture |
| + * User interface mockup: What should the interface look like for validating connections? |
| + ** |
| + |
| + * SMS backend services |
| + ** when a relation is connected to an input and ouptut port, a change event will be caught, and an sms method will be called, passing in the output actor-port pair, the input actor-port pair, and the workflow itself. |
| + ** the sms method will reply with three states: valid, invalid, and unknown, which the even handler will use to code the relation with (to show these cases). Also, a textual description of why the match is invalid may be useful ... but we may get to this more in the next step, which is helping a user "fix" the connection |
| + ** it would be useful to do the same thing with datatypes |
| + {{{ |
| + public SemtypeValidityCheckResult isSemtypeCompatibleConnection(LSID workflowId, Connection connection); // connection within wf |
| + }}} |
| + |
| + |
| + |
| + {{{ |
| + SMS backend services |
| + User interface mockup |
| + Ontology needs assessment |
| + Tasks and milestones |
| + }}} |
Back to SMS_KR Developers Meeting Notes May 2005,
or to the Page History.
|
