-
-
Notifications
You must be signed in to change notification settings - Fork 62
Add description of saladVersion
#861
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
5448ca8
d4eef04
15cb5bd
50107f0
31bc518
419c382
55bf75e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,4 @@ | ||
| saladVersion: v1.3 | ||
| $base: "https://w3id.org/cwl/salad#" | ||
|
|
||
| $namespaces: | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -104,6 +104,7 @@ enhance code generation by representing CWL data types as specific Python object | |
| * Support for the Avro `map` schema | ||
| * Add named versions of the `map` and `union` Avro types | ||
| * Support for nested named `union` type definitions | ||
| * Add description of `saladVersion` | ||
|
|
||
| ## References to Other Specifications | ||
|
|
||
|
|
@@ -196,6 +197,7 @@ It is a fatal error if the document is not valid YAML. | |
|
|
||
| A Salad document must consist only of either a single root object or an | ||
| array of objects. | ||
| Each document must declare the `saladVersion` of that document. Implementations must validate against the document's declared version. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This Option 1: substitute this clause with
Option 2: substitute row 212 with
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer the option 2.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I totally agree to go with option 2 here.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I fixed the row 212 to take the option 2. |
||
|
|
||
| ## Document context | ||
|
|
||
|
|
@@ -207,8 +209,9 @@ load the document. It may be overridden by an explicit context. | |
|
|
||
| ### Explicit context | ||
|
|
||
| If a document consists of a root object, this object may contain the | ||
| fields `$base`, `$namespaces`, `$schemas`, and `$graph`: | ||
| If a document consists of a root object, this object must contain the | ||
| field `saladVersion` and may contain the fields `$base`, `$namespaces`, | ||
| `$schemas`, and `$graph`: | ||
|
|
||
| * `$base`: Must be a string. Set the base URI for the document used to | ||
| resolve relative references. | ||
|
|
||
Large diffs are not rendered by default.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens to
saladVersionin case of an array of objects? Each object must provide its ownsaladVersion? @mr-c @tetronThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least, it is necessary to declare
saladVersionat the root level.Otherwise, we cannot decide whether to allow the newly introduced features such as nested typeDSL and map/union types.
I guess there are two options to declare
saladVersionfor the array of objects.saladVersionsaladVersionat the root level and to allow the imported documents inherit thesaladVersionin the parent level.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Option 1 is easier to be documented but it is less practical for users.
Option 2 requires to distinguish between root Salad documents and imported Salad documents (those that are included through the
$importstatement), clearly define the two concepts, and state that a Salad document can be used as a root Salad document only if it specifies asaladVersionfield. Conversely, if imported documents do not specify asaladVersionthey inherit the one from their root Salad doument.Another problem here is dealing with mixed versions, as in CWL. What if a Salad 2.0 document imports a Salad 3.0 document, and viceversa? Is this something that Salad allows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to take a similar approach as CWL.
That is,
saladVersion, andsaladVersionrather than its parentsaladVersion.Here is the corresponding description in CWL v1.2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a technical issue for it.
The current code generator seems to hold
saladVersiononly at the root level rather than schema object level.To fix this issue, we may need to introduce
saladVersionfor each schema object in addition to the root explicit context.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tom-tan Is this fixed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not yet fixed because there is a corner case to be discussed as shown below:
@GlassOfWhiskey and I prefer the option 2 but it needs changes that may affect all the code generators.
There are several ways for option 2.
saladVersionfor each schema object as mentioned above, orcwl-normalizertypeDSLblocks this option. Related: Backported schemas tocodegenbranch may break portability between platforms due to handlingtypeDSL#863I prefer to introduce a upgrader for schema salad after fixing the
typeDSLissue.What do you think?