@@ -93,8 +93,12 @@ https://github.com/common-workflow-language/common-workflow-language/tree/master
93
93
94
94
### <a name =" map " >` map<> ` </a >
95
95
96
- The "type: ` array<ComplexType> | map<key_field, ComplexType> ` " syntax in the CWL
97
- specifications means there are two or more ways to write the given value.
96
+ Note: This section is non-normative.
97
+
98
+ The
99
+ > type: array<ComplexType > |
100
+ > map<` key_field ` , ComplexType>
101
+ syntax in the CWL specifications means there are two or more ways to write the given value.
98
102
99
103
Option one is a array and is the most verbose option.
100
104
In our example here we use the generic` ComplexType ` , but
@@ -113,6 +117,7 @@ some_cwl_field:
113
117
- key_field: a_complex_type2
114
118
field2: foo2
115
119
field3: bar2
120
+ - key_field: a_complex_type3
116
121
```
117
122
118
123
Specific example using [ Workflow.inputs] ( Workflow.html#InputParameter ) :
@@ -127,11 +132,15 @@ inputs:
127
132
- id: workflow_input02
128
133
type: File
129
134
format: http://edamontology.org/format_2572
135
+ - id: workflow_input03
130
136
```
131
137
132
138
Option two is enabled by the ` map<…> ` syntax. Instead of an array of entries we
133
139
use a mapping, where one field of the ` ComplexType ` (here named ` key_field ` )
134
- becomes the key in the map, and its value is the rest of the ` ComplexType ` .
140
+ becomes the key in the map, and its value is the rest of the ` ComplexType `
141
+ without the key field. If all of the other fields of the ` ComplexType ` are
142
+ optional and unneeded, then we can indicate this with an empty mapping as the
143
+ value: ` a_complex_type3: {} `
135
144
136
145
Generic example:
137
146
```
@@ -142,6 +151,7 @@ some_cwl_field:
142
151
a_complex_type2:
143
152
field2: foo2
144
153
field3: bar2
154
+ a_complex_type3: {} # we accept the defualt values for "field2" and "field3"
145
155
```
146
156
147
157
Specific example using [ Workflow.inputs] ( Workflow.html#InputParameter ) :
@@ -156,6 +166,7 @@ inputs:
156
166
workflow_input02:
157
167
type: File
158
168
format: http://edamontology.org/format_2572
169
+ workflow_input03: {} # we accept the default value for "type"
159
170
```
160
171
161
172
Sometimes we have a third and even more compact option denoted like this:
@@ -170,6 +181,7 @@ Here's the generic example:
170
181
some_cwl_field:
171
182
a_complex_type1: foo # we accept the default value for field3
172
183
a_complex_type2: foo2 # we accept the default value for field3
184
+ a_complex_type3: {} # we accept the defualt values for "field2" and "field3"
173
185
```
174
186
175
187
Specific example using [ Workflow.inputs] ( Workflow.html#InputParameter ) :
@@ -181,6 +193,7 @@ Specific example using [Workflow.inputs](Workflow.html#InputParameter):
181
193
inputs:
182
194
workflow_input01: string
183
195
workflow_input02: File # we accept the default of no File format
196
+ workflow_input03: {} # we accept the default of no "type"
184
197
```
185
198
186
199
@@ -194,6 +207,8 @@ some_cwl_field:
194
207
field2: foo2
195
208
field3: bar2 # we did not accept the default value for field3
196
209
# so we had to use the slightly expanded syntax
210
+ my_complex_type3: {} # as before, we accept the default values for both
211
+ # "field2" and "field3"
197
212
```
198
213
199
214
Specific example using [ Workflow.inputs] ( Workflow.html#InputParameter ) :
@@ -204,16 +219,19 @@ Specific example using [Workflow.inputs](Workflow.html#InputParameter):
204
219
```
205
220
inputs:
206
221
workflow_input01: string
207
- workflow_input02: # we use the longer way
208
- type: File # because we want to specify the format too
222
+ workflow_input02: # we use the longer way
223
+ type: File # because we want to specify the " format" too
209
224
format: http://edamontology.org/format_2572
225
+ workflow_input03: {} # back to the short form as this entry
226
+ # uses the default of no "type" just like the prior
227
+ # examples
210
228
```
211
229
212
230
213
231
Note: The ` map<…> ` version is optional, the verbose option #1 is always allowed,
214
232
but for presentation reasons option 3 and 2 may be preferred by human readers.
215
233
216
- Another explanation, aimed at implementors, is in the
234
+ The normative explanation for these variations , aimed at implementors, is in the
217
235
[ Schema Salad specification] ( SchemaSalad.html#Identifier_maps ) .
218
236
219
237
## Identifiers
0 commit comments