Merge branch 'master' into rc1_feedback

Author: Peter Amstutz

CommandLineTool.yml

@@ -10,10 +10,10 @@ $graph:
   type: documentation
   doc:
     - |
-      # Common Workflow Language (CWL) Command Line Tool Description, v1.1.0-dev1
+      # Common Workflow Language (CWL) Command Line Tool Description, v1.1
 
       This version:
-        * https://w3id.org/cwl/v1.1.0-dev1/
+        * https://w3id.org/cwl/v1.1/
 
       Current version:
         * https://w3id.org/cwl/
@@ -37,17 +37,17 @@ $graph:
     - {$include: intro.md}
 
     - |
-      ## Introduction to the CWL Command Line Tool standard v1.1.0-dev1
+      ## Introduction to the CWL Command Line Tool standard v1.1
 
       This specification represents the latest development release from the
       CWL group.  Since the v1.0 release, v1.1 introduces the
       following updates to the CWL Command Line Tool standard.
-      Documents should use `cwlVersion: v1.1.0-dev1` to make use of new
-      syntax and features introduced in v1.1.0-dev1.  Existing v1.0 documents
+      Documents should use `cwlVersion: v1.1` to make use of new
+      syntax and features introduced in v1.1.  Existing v1.0 documents
       should be trivially updatable by changing `cwlVersion`, however
       CWL documents that relied on previously undefined or
       underspecified behavior may have slightly different behavior in
-      v1.1.0-dev1.
+      v1.1.
 
       ## Changelog
 
@@ -121,7 +121,7 @@ $graph:
           type, or a valid expression which returns a value having one
           of the the other types defined for that field.
 
-      See also the [CWL Workflow Description, v1.1.0-dev1 changelog](Workflow.html#Changelog).
+      See also the [CWL Workflow Description, v1.1 changelog](Workflow.html#Changelog).
 
       ## Purpose
 

Process.yml

@@ -8,7 +8,7 @@ $namespaces:
 
 $graph:
 
-- name: "Common Workflow Language, v1.1.0-dev1"
+- name: "Common Workflow Language, v1.1"
   type: documentation
   doc: {$include: concepts.md}
 
@@ -38,7 +38,8 @@ $graph:
     - cwl:draft-4.dev3
     - cwl:v1.0.dev4
     - cwl:v1.0
-    - cwl:v1.1.0-dev1 # a dash is required by the semver 2.0 rules
+    - cwl:v1.1.0-dev1   # a dash is required by the semver 2.0 rules
+    - cwl:v1.1
 
 - name: CWLType
   type: enum

README.md

@@ -6,4 +6,4 @@ Proposed changes that aren't yet implemented are tracked at https://github.com/c
 
 You can render this using https://github.com/common-workflow-language/cwl-website/blob/master/website.sh
 
-The current rendering is at https://www.commonwl.org/v1.1.0-dev1/
+The current rendering is at https://www.commonwl.org/v1.1/

Workflow.yml

@@ -11,10 +11,10 @@ $graph:
   type: documentation
   doc:
     - |
-      # Common Workflow Language (CWL) Workflow Description, v1.1.0-dev1
+      # Common Workflow Language (CWL) Workflow Description, v1.1
 
       This version:
-        * https://w3id.org/cwl/v1.1.0-dev1/
+        * https://w3id.org/cwl/v1.1/
 
       Current version:
         * https://w3id.org/cwl/
@@ -35,17 +35,17 @@ $graph:
 
     - |
 
-      ## Introduction to CWL Workflow standard v1.1.0-dev1
+      ## Introduction to CWL Workflow standard v1.1
 
       This specification represents the latest stable release from the
-      CWL group.  Since the v1.0 release, v1.1.0-dev1 introduces the
+      CWL group.  Since the v1.0 release, v1.1 introduces the
       following updates to the CWL Workflow standard.
-      Documents should to use `cwlVersion: v1.1.0-dev1` to make use of new
-      syntax and features introduced in v1.1.0-dev1.  Existing v1.0 documents
+      Documents should to use `cwlVersion: v1.1` to make use of new
+      syntax and features introduced in v1.1.  Existing v1.0 documents
       should be trivially updatable by changing `cwlVersion`, however
       CWL documents that relied on previously undefined or
       underspecified behavior may have slightly different behavior in
-      v1.1.0-dev1.
+      v1.1.
 
       ## Changelog
 
@@ -104,7 +104,7 @@ $graph:
           type, or a valid expression which returns a value having one
           of the the other types defined for that field.
 
-      See also the [CWL Command Line Tool Description, v1.1.0-dev1 changelog](CommandLineTool.html#Changelog).
+      See also the [CWL Command Line Tool Description, v1.1 changelog](CommandLineTool.html#Changelog).
 
       ## Purpose
 

concepts.md

@@ -92,12 +92,12 @@ preprocessing steps described in the
 [Semantic Annotations for Linked Avro Data (SALAD) Specification](SchemaSalad.html).
 An implementation may formally validate the structure of a CWL document using
 SALAD schemas located at
-https://github.com/common-workflow-language/common-workflow-language/tree/master/v1.1.0-dev1
+https://github.com/common-workflow-language/common-workflow-language/tree/master/v1.1
 
 ### map
 
 Note: This section is non-normative.
-> type: array<ComplexType> |  
+> type: array<ComplexType> |
 > map<`key_field`, ComplexType>
 
 The above syntax in the CWL specifications means there are two or more ways to write the given value.
@@ -117,7 +117,7 @@ some_cwl_field:
 ```
 
 Option one specific example using [Workflow](Workflow.html#Workflow).[inputs](Workflow.html#WorkflowInputParameter):
-> array<InputParameter> |  
+> array<InputParameter> |
 > map<`id`, `type` | InputParameter>
 
 
@@ -150,7 +150,7 @@ some_cwl_field:
 ```
 
 Option two specific example using [Workflow](Workflow.html#Workflow).[inputs](Workflow.html#WorkflowInputParameter):
-> array<InputParameter> |  
+> array<InputParameter> |
 > map<`id`, `type` | InputParameter>
 
 
@@ -164,7 +164,7 @@ inputs:
 ```
 
 Option two specific example using [SoftwareRequirement](#SoftwareRequirement).[packages](#SoftwarePackage):
-> array<SoftwarePackage> |  
+> array<SoftwarePackage> |
 > map<`package`, `specs` | SoftwarePackage>
 
 
@@ -180,7 +180,7 @@ hints:
 ```
 `
 Sometimes we have a third and even more compact option denoted like this:
-> type: array<ComplexType> |  
+> type: array<ComplexType> |
 > map<`key_field`, `field2` | ComplexType>
 
 For this example, if we only need the `key_field` and `field2` when specifying
@@ -207,7 +207,7 @@ inputs:
 ```
 
 Option three specific example using [SoftwareRequirement](#SoftwareRequirement).[packages](#SoftwarePackage):
-> array<SoftwarePackage> |  
+> array<SoftwarePackage> |
 > map<`package`, `specs` | SoftwarePackage>
 
 
@@ -248,7 +248,7 @@ inputs:
 ```
 
 Mixed option 2 and 3 specific example using [SoftwareRequirement](#SoftwareRequirement).[packages](#SoftwarePackage):
-> array<SoftwarePackage> |  
+> array<SoftwarePackage> |
 > map<`package`, `specs` | SoftwarePackage>
 
 
@@ -404,7 +404,7 @@ as if they were specified there.
 Requirements specified in a parent Workflow are inherited by step processes
 if they are valid for that step. If the substep is a CommandLineTool
 only the `InlineJavascriptRequirement`, `SchemaDefRequirement`, `DockerRequirement`,
-`SoftwareRequirement`, `InitialWorkDirRequirement`, `EnvVarRequirement`, 
+`SoftwareRequirement`, `InitialWorkDirRequirement`, `EnvVarRequirement`,
 `ShellCommandRequirement`, `ResourceRequirement` are valid.
 
 *As good practice, it is best to have process requirements be self-contained,