[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 ]
Michael Pizzo updated ODATA-940:
--------------------------------
Proposal:
Define a new term for "AllowedValues", as part of the Validation vocabulary:
<Term Name="AllowedValues" Type="Validation.ValueEnumeration)">
<Annotation Term="Core.Description" String="A collection of valid values for the annotated property or parameter" />
</Term>
<ComplexType Name="ValueEnumeration">
<Property Name="Extends" Type="Edm.String">
<Annotation Term="Core.Description" String="The name of a TypeDefinition with the same Underlying Type that has a ValueEnumeration annotation whose values are extended by this annotation"/>
</Property>
<Property Name="Values" Type="Collection(Edm.Primitive)"/>
</ComplexType>
That could then be used, for example:
<TypeDefinition Name="Weekdays" UnderlyingType="Edm.String">
<Annotation Term="AllowedValues">
<Record>
<PropertyValue Property="Values">
<Collection>
<String>Monday</String>
<String>Tuesday</String>
<String>Wednesday</String>
<String>Tursday</String>
<String>Friday</String>
</Collection>
</PropertyValue>
</Record>
</Annotation>
</TypeDefinition>
<TypeDefinition Name="Days" UnderlyingType="Edm.String">
<Annotation Term="AllowedValues">
<Record>
<PropertyValue Property="Extends" String="ns.WeekDays"/>
<PropertyValue Property="Values">
<Collection>
<String>Saturday</String>
<String>Sunday</String>
</Collection>
</PropertyValue>
</Record>
</Annotation>
</TypeDefinition>
was:
Define a new term for "AllowedValues", as part of the Validation vocabulary:
<Term Name="AllowedValues" Type="Validation.ValueEnumeration)">
<Annotation Term="Core.Description" String="A collection of valid values for the annotated property or parameter" />
</Term>
<ComplexType Name="ValueEnumeration">
<Property Name="Extends" Type="Edm.String"/>
<Property Name="Values" Type="Collection(Edm.Primitive)"/>
</ComplexType>
That could then be used, for example:
<TypeDefinition Name="Weekdays" Type="Edm.String">
<Annotation Term="AllowedValues">
<Record>
<PropertyValue Property="Values">
<Collection>
<String>Monday</String>
<String>Tuesday</String>
<String>Wednesday</String>
<String>Tursday</String>
<String>Friday</String>
</Collection>
</PropertyValue>
</Record>
</Annotation>
</TypeDefinition>
<TypeDefinition Name="Days" Type="Edm.String">
<Annotation Term="AllowedValues">
<Record>
<PropertyValue Property="Extends" String="ns.WeekDays"/>
<PropertyValue Property="Values">
<Collection>
<String>Saturday</String>
<String>Sunday</String>
</Collection>
</PropertyValue>
</Record>
</Annotation>
</TypeDefinition>
> 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]