OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[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:all-tabpanel ]

Ralf Handl updated ODATA-940:
-----------------------------

    Description: 
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

  was:
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


> 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]