1. #N12 Additional variable types (including non-scalar) [e.g. #S2 Interoperability; identifier comes from “Version 1.1 Candidate Items” spreasheet on TC Documents page] SDD 1.1 Proposal XXX = [Proposal | Initial Discussion | General Direction Proposal]

2. Current Situation Extend the set of variable types: –Available variable types in V1.0 shall be extended with more types, including non-scalar types (non such available in v1.0) –Currently following types are available IntegerParameterType (extends BaseParameterType) StringParameterType (extends BaseParameterType) BooleanParameterType (extends BaseParameterType) URIParameterType (extends BaseParameterType) ResourcePropertyType DerivedVariableType

3. Proposal The idea is additionally to BaseParameterType to introduce new ComplexParameterType with two subtypes –SequenceParameterType –ArrayParameterType These are defined as composites of BaseParameterType

4. Scenario(s)/Use Case(s) Let’s recall the variables definition: Variables provide a way to associate user inputs, resource property values, fixed strings and values derived from these with input arguments for artifacts and with constraints on resources. It makes sense to define two more variable types –a sequence of elements of different base types – to structure parameters that belong logically together (user account for example) –array of the same base type – to declare unknown number of common inputs (file locations for example) With respect to the purpose of variables in SDD I was not able to define a use case where table-structure may be used therefore the proposal does not contain a table

5. Proposed Schema Extend ParametersType with two more elements – SequenceParameter and ArrayParameter Create new complex type ComplexParameterType Create two extensions of ComplexParameterType –SequenceParameterType –ArrayParameterType

6. Proposed Schema ParametersType ComplexParameterType vs BaseParameterType

7. Proposed Schema SequenceParameterType

8. Proposed Schema ArrayParameterType

9. Examples SequenceParameterType 1. 2. 3. 4. ArrayParameterType 1. 2. 3. 4.

10. Issues and alternatives SequenceParameterType –Proposed change reuses well existing base types in the sequence –Base type IDs become sub-element IDS –DefaultValues and other properties of base types fit well –Do operation and required attributes in subelements have sense when sequence element defines such or are inherited? ArrayParameterType –Sub-elements in array define the type well –Default Values in sub-elements define default array values –Sub-element IDs do not fit well to the array concept –Empty array is declared somehow strange – with one sub-element requiring one “dummy” ID –Do operation and required attributes in subelements have sense when sequence element defines such or are inherited? Alternatives - Overall the issues come from the fact that base-types merge the idea of data type and of named parameter. They are defined as “parameter-types” not as “pure data types”. This makes their reuse in complex types somehow unnatural. –A1: Define alternatives to base types as pure data type – no ID, required, operation, defaultValue, sensitive attributes –A2: Keep sequence type as it is but redefine arrays as IntegerArray, StringArray, etc…

11. Proposed Schema Change 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.

12. Proposed Schema Change 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

13. Proposed Schema Change 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.