[OASIS Issue Tracker] (ODATA-964) Need to clarify nested delta representation

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

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

Michael Pizzo commented on ODATA-964:
-------------------------------------

The things we can express in delta:
-Added member
-Update member
-Added Link
-Deleted member
-Deleted Link

The first three we already have semantics for in a nested payload.  For containment, the last two are identical.

One option might be to support the deleted entity in a nested payload but not added/deleted links. The deleted entity already has reasons for "deleted" and "changed"; we could use those to distinguish between a deleted entity and a deleted link in the non-nested case.  No supporting added/deleted links makes it easier to scope the support of the changes to the current nested collection (technically, a deleted entity could come from anywhere, but the semantics would be that it would no longer be a member of this collection, whether it ever was or not).

> Need to clarify nested delta representation
> -------------------------------------------
>
>                 Key: ODATA-964
>                 URL: https://issues.oasis-open.org/browse/ODATA-964
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>         Environment: Proposal needed for CSD01
>            Reporter: Michael Pizzo
>            Assignee: Michael Pizzo
>             Fix For: V4.01_WD01
>
>
> In OData-876 we defined a format for representing nested changes in-line within a delta format. In OData-613 we said you could use PATCH to update a collection using a delta format, and added the following to ODATA-876:
> "You can use contextUrl (ending in /$delta) on the navigation property to specify that the nested content is a delta content (partial update with patch semantics that can contain added/deleted links and tombstones)."
> The above text implies that you can have a delta format nested within a navigation property for an otherwise non-delta format. However, this brings up some issues, since the delta format was defined as a flat format. In particular, 
> 1) what is the format/content of the contextUrls required for added links, deleted links, and deleted entries
> 2) are there any restrictions on the scope of the added/delete links (and tombstones); do they have to be at all related to the nav prop?
> Option 1 would be to use contextUrls such as the following:
> { 
>   "@odata.type":"#Northwind.Manager",
>   "FirstName" : "Patricia",
>   "DirectReports@odata.contextUrl" : "#Employees(1)/DirectReports/$delta",
>   "DirectReports": [
>     {
>       "@odata.context":"#Employees/$deletedEntity",
>       "id":"Employees(3)",
>       "reason":"deleted"
>     },
>     {
>       "@odata.context":"#Employees/$deletedLink",
>       "source":"Employees(1)",
>       "relationship":"DirectReports",
>       "target":"Employees(4)"
>     },
>     {
>       "@odata.context":"#Employees(1)/$link",
>       "source":"Employees(1)",
>       "relationship":"DirectReports",
>       "target":"Employees(5)"
>     },
>     {
>       "@odata.context":"#Employees/DirectReports/$entity",
>       "FirstName": "Suzanne",
>       "LastName": "Brown"
>     }
>   ]
> }
> Option 2 would be to prohibit use of delta format for nested nav props within a non-delta format.



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