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-494) Add possibility for enumeration types to "extend" other enumerations

    [ https://issues.oasis-open.org/browse/ODATA-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60683#comment-60683 ] 

Michael Pizzo commented on ODATA-494:

The ability for a service to return a new value that the client wasn't expecting is likely to break clients. The scenario of extending enumerations from custom vocabularies could be achieved by extending the definition, without introducing an inheritance hierarchy.

> Add possibility for enumeration types to "extend" other enumerations
> --------------------------------------------------------------------
>                 Key: ODATA-494
>                 URL: https://issues.oasis-open.org/browse/ODATA-494
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL
>    Affects Versions: V4.0_CS01
>            Reporter: Michael Pizzo
>            Assignee: Michael Pizzo
>              Labels: GoodIdea
>             Fix For: V4.01_WD01
> We currently don't have a way for adding values to an enumeration type. This would be helpful for defining custom vocabularies that extend base vocabularies. 
> However, defining inheritance for enumerations introduces substitutability that is likely to break clients by returning new enumeration values not anticipated by the client (for instance, in a switch statement).
> An alternative to inheritance would be to introduce the ability for an enumeration type to *definitionally* extend an existing enumeration type.  This is similar to what we do with entity containers, which can extend the definition of an existing container without introducing any substitutability.
> We could even use the same "Extends" attribute, rather than "BaseType" which implies inheritance.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]