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-812) Allow omitting namespaces for unambiguous functions/actions

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

Ralf Handl commented on ODATA-812:

Hi Evan, bound actions/functions can be defined with the abstract Edm.EntityType as their binding parameter type, implying that they can be applied to any entity in that service. We do have use cases for (at least SAP-)shared vocabularies that will define common bound actions/functions that can potentially be applied to any entity of a service that supports this shared vocabulary. ODATA-619 also is connected to this: it would allow to "group" several of these "abstract" actions/functions into an "interface" and tag entity types that support this "interface" with the grouping term, being more specific on where the abstract actions/functions can actually be applied. Of course the target audience for this are generic client components that don't have esthetic opinions regarding to URL style, so these don't need the shortcut syntax defined here and won't run into ambiguities because they will use qualified actions/functions anyway.

Back to the discussion: I like Steven's proposal of a term that explicitly tells where the syntactic sugar can be used. Especially because not all services will support this optional feature.

> Allow omitting namespaces for unambiguous functions/actions
> -----------------------------------------------------------
>                 Key: ODATA-812
>                 URL: https://issues.oasis-open.org/browse/ODATA-812
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>    Affects Versions: V4.0_ERRATA02
>            Reporter: Michael Pizzo
>              Labels: AdoptionBlocker
>             Fix For: V4.01_WD01
> I hear a lot of pushback on having to qualify functions/actions when invoking.
> We can support unqualified function/actions as long as they don't conflict with any properties.

This message was sent by Atlassian JIRA

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