[OASIS Issue Tracker] Updated: (ODATA-454) Need a way to specify a property is unavailable

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

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

Ralf Handl updated ODATA-454:
-----------------------------

    Proposal: 
1) Define a core term that can be used as a data/metadata annotation:

<Term Name="Permission" Type="Core.PermissionType" AppliesTo="Edm.Property"/>
<EnumType Name="PermissionType" Flags="true">
  <Member Name="None" Value="0" />
  <Member Name="Read" Value="1" />
  <Member Name="Write" Value="2" />
  <Member Name="ReadWrite" Value="3" />
</EnumType>

2) Allow the service to omit properties from the payload that are specified in metadata, even if they are selected. Such omitted properties have no value (as distinct from null) and should be annotated with the Core.Inaccessible term. Instances with omitted values for properties that appear in the $filter expression are excluded from the result. Accessing an omitted value returns 404.

3) In the payload, properties that the client does not have permission to read are omitted from the payload (no data:property-name element in ATOM and no name/value pair in JSON) and annotated with the "None" permission.

  was:
1) Define a core term that can be used as a data/metadata annotation:

<Term Name="Permission" Type="Core.PermissionType" AppliesTo="Edm.Property"/>
<Enumeration Name="PermissionType" Flags="true">
  <Member Name="None" Value="0" />
  <Member Name="Read" Value="1" />
  <Member Name="Write" Value="2" />
  <Member Name="ReadWrite" Value="3" />
</Enumeration>

2) Allow the service to omit properties from the payload that are specified in metadata, even if they are selected. Such omitted properties have no value (as distinct from null) and should be annotated with the Core.Inaccessible term. Instances with omitted values for properties that appear in the $filter expression are excluded from the result. Accessing an omitted value returns 404.

3) In the payload, properties that the client does not have permission to read are omitted from the payload (no data:property-name element in ATOM and no name/value pair in JSON) and annotated with the "None" permission.


How is Core.Inaccessible defined?

Why do we need Write as an explicit value? Write-only properties that cannot be read seem counter-intuitive.

I propose

<EnumType Name="PermissionType">
  <Member Name="None" />
  <Member Name="Read" />
  <Member Name="Full" />
</EnumType>

> Need a way to specify a property is unavailable
> -----------------------------------------------
>
>                 Key: ODATA-454
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-454
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData ATOM Format , OData JSON Format, Vocabularies
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.0_CSD02
>
>
> We have added the ability for services to select the set of properties returned in a feed or individual entity, which allows the service to optimize results (for example, when sending to a device). However, we currently require that the service specify in the metadata url the set of properties returned, and that each entity in the result contain the same set of properties.
> There are times when a particular property is not available to the client (for example, due to permissions), and that permission may vary between different elements of a feed. For example, a manager may be able to see salaries for those reporting to them but not to their peers. It's wrong to report "null" for the salaries of their peers; their peers have a salary, it's just not available to them.
> We could define a "Permissions" term in either core or capabilities vocabularies that could apply to an entity set or property in metadata and could be overwritten in the instance data.
> It is important to do this in V4, so that client know to look for this annotation in the absence of a value for a property. We might want to rationalize this with permissions for update versus readonly in the capabilities vocabulary.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira