Is there a default value transient and passthru properties ?

[tcezard]

I didn't review #96 properly and realised after it was merged that we were not adding transient and passthru for each properties.
It might make sense not to add them because they are an implementation choice.
However this leave with a few options:

1. transient & passthru default to false if not set in the service-info

This would have the advantage of not having to set them unless deviating from the default. It also "feels" right because the transient and passthru properties have some special status (they behave differently from the others) so it makes sense that they would require additional information in the service-info.
However, if this is the case, we should make it clear in the specification and unless I missed it, we're not at the moment.

2. transient & passthru have no default but are set in the minimal/extended schema

This would be similar to how we treat collated so would be better for consistency. However that would force use to make a decision on which property is transient or collated and allow implementations to override this in their own schema definition. This might prevent implementation from deviating from what we set in the central schema.
Again that should be said explicitly in the specification

3. transient & passthru have no default and are not set in the minimal/extended schema

I believe this is the current state of the specification at the time of writing.
I think this prevent the effective reuse of the central schema as described in #100 because each implementation will have to specify the transient=false and passthru=false

My vote is for option 1.

[sveinugu]

I also did not review this in detail.

I believe we agreed to treat transient and passthru differently in that passthru is bound to the attribute (part of the definition), while transient is implementation-specific and set alongside required at the outer level in the schema. In the extended schema, transient is set at the outer level, while passthru is not included at all as none of the current attributes are passthru. As such, I would assume that @nsheff already treats the default value of passthru as false, which makes sense to me.

As transient is defined alongside required in the form of an array of attribute names, there are actually two different ways in which to define a default value for transient:

A. The default value for an attribute that is not included in the qualifier array.

Here, it is natural to treat the default for transient as false if not included in the ga4gh.transient array, as this is how required works in JSON Schema. By extension, I would also say the default value of inherent is also false for an attribute not included in the ga4gh.inherent array. I would say all of these defaults have been assumed to work in this way, but it has never explicitly stated until now.

B. Should we have a default value of the ga4gh.transient array itself, if not specified?

This is related to the required and ga4gh.inherent arrays, which are recommended to be set to ['names', 'lengths', 'sequences'] and ['names', 'sequences'], respectively. One could argue for these recommendations being the default values if required or ga4gh.inherent is not specified in the service info schema. However this breaks with how JSON Schema works, where required is assumed to be an empty array if not specified. Hence, I think we should similarly treat the default value of all of these qualifier specifications as an empty array. Furthermore, since I don't believe not specifying any attributes as required and/or inherent (i.e. empty array as the default value) makes much sense for seqcol, I think we should mandate that these two are explicitly specified in the service info schema to avoid confusion. Since an empty array as default value for the ga4gh.transient qualifier specification on the other hand DOES make sense, I think we should not mandate ga4gh.transient to be specified in a service info schema, and if not specified, no attributes are transient (default value is the empty array).

Lastly, one could also treat the default value of collated as false in the same way as passthru.

In conclusion, I support your option 1, with the details as follows:

• The default value for a qualifier in the context of a single attribute is false for all of collated, passthru, required, transient, and inherent
• The default value for the required, ga4gh.inherent and ga4gh.transient qualifier specification properties is [], however the specification of required and ga4gh.inherent is mandated due to their importance.

[tcezard]

Thanks @sveinugu , I actually somewhat forgot about the distinction between local and global qualifier.
Looking back at the spec it seems that both passthru and transient are global qualifiers.
In section 4.7 Method of specifying attribute qualifiers

We reasoned that inherent, transient, and passthru are global qualifiers, like required, which describe the role of an attribute in the context of the whole object.

[nsheff]

Yes, we debated, but finally decided that all of these should be global qualifiers.

To me, all of these qualifiers default to false.

[nsheff]

I guess to me this was pretty clear. All of these qualifiers operate exactly the same way the built-in required qualifier works. They are opt-in. An attribute is not required unless you specify it is required.

They all work the same way.

That's equivalent to saying they all default to false.

[sveinugu]

Yes, we debated, but finally decided that all of these should be global qualifiers.

To me, all of these qualifiers default to false.

Sorry, forgot about that. The lack of passthru in the schemas is anyway due to there being no passthru attributes.

Two questions remain, though.

1. Does collated as a local qualifier also default to false? (I think yes)

2. Do we add restrictions to required and/or ga4gh.inherent? Such as: Mandate that they are always present? Always non-empty? Inherent a subset of required?

We can in any case come back to 2, as we are very much talking edge cases here. My main thought here is that without inherent the level 0 digest algorithm is undefined, and programmatically thinking, one should always define edge cases to avoid bugs.

[nsheff]

I will clarify this in the current spec by adding to section 4.