[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-940) Define a validation term for valid values
[ https://issues.oasis-open.org/browse/ODATA-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62509#comment-62509 ] Ralf Handl commented on ODATA-940: ---------------------------------- I'd start without the "extend" or "merge" feature and instead require that all allowed values are listed. I would however make the term structured so we can add additional properties later, and I'd also go for Validation.Value as a complex type that allows annotating/documenting each allowed value. Annotating enumeration values is currently discussed for the OpenAPI Specification in https://github.com/OAI/OpenAPI-Specification/issues/348, so this seems to be a general concern/desire. > Define a validation term for valid values > ----------------------------------------- > > Key: ODATA-940 > URL: https://issues.oasis-open.org/browse/ODATA-940 > Project: OASIS Open Data Protocol (OData) TC > Issue Type: Bug > Components: Vocabularies > Affects Versions: V4.0_ERRATA03 > Environment: [Proposed] > Reporter: Michael Pizzo > Fix For: V4.01_WD01 > > > ODATA-849 proposes allowing enumerations to extend other enumerations. > ODATA-494 similarly proposes allowing enumerations to derive from other enumerations. > ODATA-874 proposes allowing string as an underlying type > We have also had requests to support enumerations that don't conform to the rules for simple identifiers (i.e., they may have spaces, dashes, etc. in the names) > All of these are good suggestions, but they don't play well with enumerations in programming languages. > As an alternative to trying to introduce rules that don't work well with programming languages, we could simply extend the validation vocabulary with a term that could be applied to any property in order to limit the domain of valid values for that property, or defined as a type definition such that any property that used that type definition would have the constraint. > The semantics of this new construct would be clear up front that it could change over time, so applications would need to account for unexpected values. > This could be used where an enumeration was not appropriate, for example: > 1) Where the allowable values needed to change over time > 2) Where the allowable values needed to extend an existing allowable values > 3) Where the allowable values were not (all) strings > 4) Where the allowable values did not satisfy simple identifier rules -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]