runtime parameter with multiple values

[keighrim]

We discussed in the linked issue (below) to enable a multi-value runtime parameter. tl,dr; We want to tell a text box detection app to use both slate and credit TimeFrames (and possibly more) at the runtime.

This issue to track discussion and implementation of the proposal in the comment.

---

Also, here are we assuming that the options for property keys and values are fixed? If a new tool is added that produces a new type for frameType, will downstream apps need to be updated to allow that frame type as a parameter?

I think that's true if the parameter specification of the downstream app uses choices field. One can define a parameter without more-constraining choices but loosely specify possible values in the human readable text (in description field).

Is the objection against not having the frameType=text part in the input?

Yes. The input object is under-specified in that the app in fact wants certain kinds of TimeFrame, but any.

"multiple-select-allowed": "true",

I like this idea. With recent conversation with GBH, we might want to add a parameter to pick labels of interest to the spacy NER app. We can either go with whitelisting or blacklisting, but at the end of the day it can look something like this;

"parameters": 
 {
   "name": "discard-ne-label",  # going with a blacklist
   "type": "string",
   "choices": ["person", "organization", "date", "ord", ... ],
   "multiple-select-allowed": "true", 
   "description": "make app to ignore certain NE labels in the output MMIF"
 }

And finally on the URL form for multi choice params, I also prefer a succinct form

https://someapp/?run-on-timeframe=slate,credits

But, I also believe going with repeating the key with each value is a safer way

https://someapp/?run-on-timeframe=slate&run-on-timeframe=credits

Simply because in the succinct form, we have to worry about parameter values that (possibly) include literal commas , in them, even though that's not so likely to happen.

Originally posted by @keighrim in https://github.com/clamsproject/clams-python/issues/29#issuecomment-854893951

[keighrim]

A few points to decide;

1. URL format for the multi-valued parameters. Two methods were suggested in the above. For the safety reason I said in the above, my vote is for repeated keys (key=val1&key=val2). Also flask supports convenient parsing of such multi-valued query strings.
2. What to do when two or more values are passed to a parameter that doesn't allow multi-value? Either the first or the last value should be used. In the case of flask, it only keeps the first value.
3. the name of the key to use to allow a parameter to allow multiple values. In the current commit in the PR, I arbitrarily used allow_many.