Hi Richard, RFC6902 doesn't allow extension operators; you'd need to define a new media type and specify its behaviour. Of course, you could do that pretty easily by just saying "here's a new media type; it has the same semantics / requirements as JSON Patch, plus this...".
Also, I trust you've seen the new JSON merge-patch RFC (I think we spoke about it before)? https://tools.ietf.org/html/rfc7386 Cheers, On 15 Oct 2014, at 4:47 am, Y. Richard Yang <[email protected]> wrote: > Dear all, > > Some of us are having an extensive discussion on how to proceed regarding the > ALTO incremental updates WG item. Here is a summary of what we are thinking. > At a high level, we plan to propose an approach of using JSON Patch > (RFC6902), but with some extensions. We want to get your comments and advice > on if you see any problems, and how best to proceed. > > Current state: > ========== > Both JSON Patch (RFC6902) and > http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 are considered as > candidates of the encoding update message format. > > Design goal and problem: > ==================== > Generality and efficiency. That is, we want an incremental update format that > can handle not only current resources but also future resources. The recent > trend in adopting YANG shows that general mechanisms, not per protocol patch, > have value. Generic encoding of JSON Patch based on XPATH and a few operators > is complete in this sense, but inefficient in key ALTO cases such as updating > cost maps, as pointed out in > http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 > > Key idea: > ======= > A JSON object can be considered as an key-value tree, with each node being an > object and each edge labeled by the key, and the value of the edge pointing > to another object. For example, the ALTO cost map example: > { > "meta" : { > > "dependent-vtags" : [ > {"resource-id": "my-default-network-map", > "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" > } > ], > > "vtag": > {"resource-id": "COST-MAP-ID", "tag": "CM-TAG"}, > > "cost-type" : {"cost-mode" : "numerical", > "cost-metric": "routingcost" > } > }, > "cost-map" : { > "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, > "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, > "PID3": { "PID1": 20, "PID2": 15 } > } > > defines a data tree with 14 leaf nodes: > > "meta/dependent-vtags/resource-id": "my-default-network-map", > "meta/dependent-vtags/tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e", > ... > "cost-map/PID3/PID1": 20, > "cost-map/PID3/PID2": 15 > > RFC6902 focuses on encoding updating one node on the tree at a time. On the > other hand, one can realize that the cost-map update encoding of > http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 updates a set of > nodes. For example, an update example > { > "meta": { > "vtag": > {"tag": "NEW-CM-TAG"}, > }, > "cost-map": { > "PID1": {"PID2": 10, "PID99": null} > } > } > updates 3 nodes. > > If one thinks about, one will realize that this is a general, interesting > design: consider the data tree of the original object; the update object is a > partial tree of the original, and updates a batch containing all matched > nodes in the partial tree. We call this operator the tree-replace operator. > How may one do this as an extension of RFC6902: > > { > "op" : "tree-replace", > "path" : "/", // prefix of update object > "value" : // just a copy of the partial object in value > { "meta": { > "vtag": > {"tag": "NEW-CM-TAG"}, > }, > "cost-map": { > "PID1": {"PID2": 10, "PID99": null} > } > } > } > > Hence, we have a simple operator that appears to be able to fix the cost-map > efficiency issue and is still general, not ALTO only. > > Next step: > ======== > - One possibility is to start to work on an extension of RFC 6902 to > introduce this operator, if there is no bug. After this is done, we specify > ALTO incremental updates using the new op. An issue is that this is a > sequential process and may take time. > > - Another possibility is that we specify JSON Patch as incremental update > encoding for now, losing efficiency. In parallel, we push for the new op, and > when it is done, ALTO incremental updates implementation can use the new op. > > - A third possibility is that we define the extension operator in ALTO > incremental updates document itself, and proceed quickly. > > Any bug in the design? Any comments or suggestions? > > Thanks! > > Richard, Wendy -- Mark Nottingham https://www.mnot.net/ _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
