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-808) Minor changes to new OnlyDeclaredProperties annotation


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

Ralf Handl updated ODATA-808:
-----------------------------

        Parent: ODATA-796
    Issue Type: Sub-task  (was: Bug)

> Minor changes to new OnlyDeclaredProperties annotation
> ------------------------------------------------------
>
>                 Key: ODATA-808
>                 URL: https://issues.oasis-open.org/browse/ODATA-808
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Sub-task
>          Components: Vocabularies
>    Affects Versions: V4.0_ERRATA02
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.0_ERRATA03
>
>
> The new "OnlyDeclaredProperties" should apply to complex types as well as entity types, since both can be open and both can have dynamic properties unless otherwise annotated.
> Also, the resolution suggested one of two alternatives; either calling the term "AdditionalProperties", consistent with the JSON Schema spec, or coming up with a name that meant dynamic properties wouldn't exist, so we could define a default and use it as a tagging term. We left it to the editors in the hopes that we could find a better name than "OnlyDeclaredProperties" for the tagging option, but since this should be the exception to what clients should be prepared to accept, I would prefer to go with the (more intuitive) option of using "AdditionalProperties" and require the service to provide the value "false" for cases where additional properties were not allowed: 
>  <Annotation Term="Core.AdditionalProperties" Bool="false"/> 
> Finally, we should define what happens if this annotation specifies that additional properties are not allowed, but the type is marked as open. A type may be defined as open in a common definition, but restricted in a particular usage, so it probably makes sense for the annotation to override the attribute.



--
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]