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-1066) Consider supporting optional operation parameters


Michael Pizzo created ODATA-1066:
------------------------------------

             Summary: 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)


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