Proposal: constraints.oneOf

[pwalsh]

As per #175

[jpmckinney]

Is it too late to rename to enum? I prefer not to create unnecessary differences between JTS and JSON Schema.

[pwalsh]

Hi @jpmckinney. As I said in original issue for this, I'm easy. Anyone else want to +1 for using enum?

[dandelany]

Here's a thought that may be a +1 for enum... I have a field which is of type 'array' and I need a constraint which basically says "each element in the array must be one of these" rather than "the entire array must be one of these". That is, my data value is eg. ['B','C','A','B'] and I'd like a constraint that looks like someConstraint: ['A','B','C']

Does it make sense to "overload" the oneOf/enum constraint to mean the former rather than the latter when type == 'array'? If so, I think calling this constraint enum makes more sense than oneOf. If not... well I guess I'll have to come up with a new name for my custom constraint :)

[dandelany]

One additional note... At first I thought overloading enum as mentioned above would be bad as it would leave no way for a field to indicate that the entire array must match a value (the original intent of enum/oneOf). This is not necessarily the case, though: enum could be treated as "the entire array must be one of these" if the value of enum is an array, and "each element must be one of these" if it's anything other than an array.

So overloading enum when field type = 'array' is definitely doable, but it still may violate the principal of least confusion. What do you guys think?

[jpmckinney]

Overloading is confusing. JSON Schema would do it like this:

{
  "type": "array",
  "items": {
    "enum": [
      "bar",
      "baz"
    ]
  }
}

The items keyword lets you set a schema for each element of the array.

With the above schema (you can test at https://json-schema-validator.herokuapp.com/), ["bar", "baz"] is valid, but ["bar", "baz", "BZZ"] is invalid.

[dandelany]

Thanks @jpmckinney, makes perfect sense. Do you think it's worth adding this to JTS as well?

[jpmckinney]

I suppose, if it's anticipated that people will be using a lot of JSON arrays within CSVs. I don't know that the use case is very well developed, though.

[pwalsh]

@jpmckinney @dandelany oneOf is trying to express something really simple.

The above examples with arrays are interesting, but I think getting out of scope as comments on this pull request that was already merged. Perhaps you want to reopen the original oneOf/enum issue.

As for what was already merged: @rgrp @paulfitz what do you think about @jpmckinney's suggestion of preferring enum over oneOf? As I wrote in original issue:

What I called oneOf above is probably more like an enum in JSON Schema. I prefer the oneOf terminology here as it fits with the more descriptive, human-oriented nature of the JTS spec, but, I'm easy.

[jpmckinney]

My response to the original reasoning is (1) if we later want something with the behavior of JSON Schema's oneOf (e.g. specifying a validation for a "date" column which can either be an integer (timestamp) or a string with the format "YYYY-MM-DD"), then we'll need to find some new term instead of just using oneOf and enum in identical meanings to JSON Schema, (2) it's almost always better to use the same terms as existing, popular prior work to avoid confusion and to avoid potential future conflicts. oneOf isn't dramatically clearer than enum. enum was chosen for JSON Schema for the second reason above: ENUM is a keyword with identical behavior in SQL (and maybe even other popular prior work). Consistent terms across multiple projects is preferable to the marginal improvement in clarity.

[pwalsh]

@jpmckinney @dandelany perhaps you want to open a new issue (more visibility) to raise the points above? Otherwise, time goes on and people will start implementing oneOf.

[jpmckinney]

See #191