...
- diff functionality for XML files (comparison of XML inside workflow and XML inside actor)
- storing new XML inside workflow
- at the moment, XML stored inside workflow is always treated as most recent one
- in case changes inside XSD/XML, in the actor, we may end up with situation where XML stored inside workflow is incompatible with required format
- we can't easily update this information (note that there were different solutions suggested but no final decision was taken)
- it's possible to use Kepler's parsing engine to update information inside workflow "as it would be modified by Kepler
there will be new feature that will allow to "inject" new code parameters into workflow
Code Block workflow-editor -updatexml file.xml -workflow ~/workflow_ets.xml -actor name_of_the_actor
- replacing XML inside workflow with one taken from actor (similar to step above, but source of the xml file will be different)
- validation of workflow's XML against actor's XSD
- this feature will allow us to determine whether code parameters inside workflow make any sense when it comes to actor's requirements
- it will allow to verify workflow's compatibility against different releases of Kepler + actors
- error handling
- at the moment, errors are not handled in nice, user friendly way - i need to fix that
- proper handling of missing actor inside workflow
- proper handling of missing actor inside Kepler
- proper handling of actor that was not generated with new FC2K features (extracted code parameters)
- helper scripts
- listing all the actors that are "broken"
- extracting XSD/XML/Default XML from workflow in human readable format (all at once)
- adding feature that will allow to analyze Kepler installaion
- list all ITM/IMAS based actors
- validate all the actors inside Kepler
- removing XSD/Default XML from workflow
- at the moment, situation is very unclear when it comes to code parameters - we are mixing sources of information
- Code Parameters (modified by user) are taken from Workflow
- XSD is always taken from actor
- Code Parameters for new actor (dropped on canvas) are taken from actor's code
- this may lead to situation where two instances of the same actor have completely different sets of parameters
- The only reasonable thing we should keep in workflow are modified code parameters (we have now ability to validate them)
- It makes no sense to keep XSD
- It makes no sense to keep Default XML
- We can introduce XML validation into workflow execution
- Once workflow is started, each and every actor that has code parameters can validate whether parameters make sense
- In case parameters are not valid we can inform user that something fishy is going on
- we need further modifications of FC2K so we can mix up actors
- at the moment, workflow-editor is not able to determine whether actor supports new functionalities or not - it blindly assumes that actors were generated using new FC2K
- i need to extend actors such way workflow-editor is capable of checking whether actor supports CodeParameters in new fashion or not
...