[OASIS Issue Tracker] (ODATA-1066) Consider supporting optional operation parameters

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/ODATA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Pizzo updated ODATA-1066:
---------------------------------

    Proposal: 
1) Add a new OptionalParameter annotation:
  <Term Name="OptionalParameter" Type="Core.Tag" DefaultValue="true" AppliesTo="Parameter">
    <Annotation Term="Core.Description" String="Supplying a value for the parameter is optional." />
  </Term>

2) All parameters marked optional must come after any parameters not marked optional

3) Keep existing rules for function overloads.

4) In function resolution:
    I) If the set of specified params exactly matches a function overload, chose it.
    ii) If the set of specified params matches a subset of parameters that includes all required parameters for exactly one function overload, choose it
   iii) otherwise, return 400 with an error stating that request was ambiguous

  was:
1) Add a new OptionalParameter annotation:
  <Term Name="OptionalParameter" Type="Core.Tag" DefaultValue="true" AppliesTo="Parameter">
    <Annotation Term="Core.Description" String="Supplying a value for the parameter is optional." />
  </Term>

2) Keep existing rules for function overloads.

3) In function resolution:
    I) If the set of specified params exactly matches a function overload, chose it.
    ii) If the set of specified params matches a subset of parameters that includes all required parameters for exactly one function overload, choose it
   iii) otherwise, return 400 with an error stating that request was ambiguous


> Consider supporting optional operation parameters
> -------------------------------------------------
>
>                 Key: ODATA-1066
>                 URL: https://issues.oasis-open.org/browse/ODATA-1066
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: CSDL JSON , CSDL XML, URL Conventions
>    Affects Versions: V4.01_WD01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.01_CSD01
>
>
> We have frequently had requests to support optional parameters, but have pushed back because they could introduce ambiguity in function resolution.
> However, with our current rules:
> 1) The unordered set of nonbinding parameter names must be unique, and
> 2) The ordered list of nonbinding parameter types must be unique
> We could support making some parameters optional as a backward compatible change with the following resolution rules:
> 1) If the set of provided parameters exactly matches all parameters of an overload, then that overload is chosen
> 2) If the set of provided parameters matches all required and a subset of optional parameters of exactly one overload, then that overload is chosen
> otherwise a 400 error
> Questions:
> 1) Should we provide a set of rules so there is never any ambiguity (i.e., there does not exist a set of parameters for which one of the two rules above is not met) or specify that the service returns 400 if the request does not resolve to a single overload?
> 2) Should we define a default value for optional parameters? This would really just be documentation (the service wouldn't need you to tell it what the default value was in metadata). It could be useful in generating strongly typed function calls in languages with optional parameters (C++, C#,...) but there may not be a static default value that can be specified (i.e., current time, a computed value, etc.)  



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)