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

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

Michael Pizzo commented on ODATA-1066:

I like the annotation because it enables a 4.0 service to support optional parameters against 4.0 clients that understand the annotation, without requiring either client or service update to 4.01.

I'm okay with $Optional in JSON.

> 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

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