You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the parameters it could be useful to define a constant that makes clear, that a parameter does not have a value (and I'm not sure if not setting a parameter is the best solution - I have to think about it), e.g. "undefined"
The text was updated successfully, but these errors were encountered:
I'm not sure we need to set defaults at the stage of declaration of parameters -- we can maybe just react to "elsewhere" cases, i.e. iterate through the values we recognize, and elsewhere do something (or nothing). Maybe, Klaus, this is also a solution to the problem that produced this issue: if we have formatConversion(inputFormat:, outputFormat:XML), then in the relevant steps of the scenario, we just assume "plain text".
Myself, I've been struggling with the idea of what exactly we can expect from parameters and how they can be handled by the SSK. For example, whether we envision (i) cases when the end user of the SSK performs the action of choosing from a list of parameters presented to them inside a scenario, or whether rather (ii) this parameter-selection process takes place at the stage of defining higher-level scenarios that use parametrized lower-level scenarios. In the latter case, flow control doesn't bother us so much (a faulty scenario with wrong or absent parameters will be caught at an earlier stage than a faulty combination of parameters selected by a user would be caught). We should have some brainstorming on that...
Only a remark, needs more elaboration:
For the parameters it could be useful to define a constant that makes clear, that a parameter does not have a value (and I'm not sure if not setting a parameter is the best solution - I have to think about it), e.g. "undefined"
The text was updated successfully, but these errors were encountered: