Decision: Default column type behavior

[arjun]

Noting a working decision to the question: What should be the default behavior when the potential for non-scalar values i.e. multi-valued or structs exist?

Decision: By default only scalar values are expected to be produced. To indicate that non-scalar value is expected, explicitly add a tag on the path with a key/value to be specified.

Smarter implementations can read parse view definitions to warn users a non-scalar value may be created and is not tagged. Implementations that truncate non-scalar values are not recommended.

[niquola]

Below is a summary of what we've discussed regarding the handling of return types in path expressions:

• Explicit Collection Return: If the path expression includes a directive that explicitly states {"return": "collection"}, then the return type should be a collection.
• Default Behavior: In the absence of explicit directives:
  If the path expression returns either 0 or 1 element, implementations can just take first.
  If the path expression returns more than one element, a runtime error should be thrown, as it is a risk to data loss.
• Compile-Time Error in Smart Engines: Advanced implementations may analyze the path expression at compile time to determine if it potentially could return multiple values. If this is detected, a compile-time error may be thrown.

[niquola]

Here is the test to capture our decision - https://github.com/FHIR/sql-on-fhir-v2/blob/master/tests/v1/traverse.json

[niquola]

I prefer to use first-class keyword aka {return: 'collection'} vs generic tags {tags: [{name, value}]} because it looks to me like a core behavior