Re: [alto] fci alto transport design discussion

[Jan Seedorf <[e-mail]>]

Hi Richard and all,

looking at RFC8008, its states that "FCI objects are composed of a 
dictionary of (key,value) pairs where the keys are the property names 
and the values are the associated property values.", meaning that the 
"capability-value" is a key. However, I did not find anything on 
multiple "capability-type" entries, and what to do when they are 
conflicting. From a CDNI perspective, it should certainly be possible to 
have something like in your example below: support http1.1 for footprint 
a and support http1.0 for footprint b.

I am for option 2) below, that is allow multiple entries with the same 
capability type.

> The FCI use case may argue that we extend the incremental update w/ 
> JSON Patch, to better handle arrays, right away.
Indeed. Do you want to choose one of the two (JSON Patch vs. JSON Merge 
Patch) or do you think of making JSON Merge Patch mandatory and JSON 
Patch optional and then we say in the ALTO FCI service specification 
that this one demands JSON Patch (as pecified in the ALTO incr. updates)?

  - Jan


On 03.07.17 13:59, Y. Richard Yang wrote:
> Hi Jan, Jon, Kevin, all,
>
> As we are working on the design, a key issue that we are trying to 
> understand is the conflict resolution of the capabilities in the 
> "capabilities" list [RFC8008]. Consider
>
>    {
>      "capabilities": [
>        {
>          "capability-type": "FCI.DeliveryProtocol",
>          "capability-value": {
>            "delivery-protocols": [
>              "http/1.1",
>            ]
>          },
>          "footprints": [
>            <Footprint objects 1>
>          ]
>        },
>        {
>          "capability-type": "FCI.DeliveryProtocol",
>          "capability-value": {
>            "delivery-protocols": [
>              "http/1.0",
>            ]
>          },
>          "footprints": [
>            <Footprint objects 2>
>          ]
>        }
>      ]
>    }
>
> What if the footprints in the two entries have overlap? I see two 
> options:
> (1) Enforce that each capability-type has a single entry; that is, 
> make capability-type a key;
> (2) Allow multiple entries with the same capability-type, and the 
> search is ordered by the array; that is, the result is the first 
> matching footprints.
>
> I assume that (2) is more flexible. An issue, however, is that it 
> makes incremental updates harder. In other words, this issue will 
> determine whether we should integrate JSON Patch. The current alto 
> incremental updates, based on SSE and JSON Merge Patch, is pretty 
> useful. The FCI use case may argue that we extend the incremental 
> update w/ JSON Patch, to better handle arrays, right away.
>
> Any clarification, comments and suggestions will be great.
>
> Richard
>

-- 
****************************
Prof. Dr. Jan Seedorf
[e-mail]
****************************
Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de
****************************