Open APIs

Dear community,

I am working an standards for our TMF API implementations and try setup guidelines for resource upate operations (PUT & PATCH).
Combining JSONPath with JSON Patch looks like a very promissing approach, keeping in mind, that the surrounding standards (RFC9535, ...) and frameworks are still evolving.

Initially I was looking for the equivalent of the "[-]" indexing of JSON Pointer to append elements to a list when I stumbled across several questions. I only refer to the JSONPath examples in TMF630 Part5 v5.0.0. The version v4.0.0/v4.2.0 shows similar challanges.

1.) The "add" operation, TMF630 v5.0.0 Part5, "5.1.1. Using JSON Path":

This chapter shows three examples, the first one is clear:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')].description", "value":"CPE Output" } ]

The path evaluates to the (not existing) element "description" of the "attachment" with id='2384..'. In this case, the the behavior of "add" as of RFC6902 is clear. Add the element 'description' and assign the value 'CPE Output'. The TMF document is consistent with the descriptions in TMF6902 here.

The second example confuses me and seems not to fit to the descriptions in RFC6902:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')]", "value": {"description":"CPE Output"} } ]

Well, the path evaluates to the element "attachment" with id='2384..'. TMF6902 describes the bahavior of "add" clearly:

If the target location specifies an object member that does exist,that member's value is replaced.

In other words, the "attachment" with id='2384..' would get the value {"description":"CPE Output"}, and lose its 'id' and all other attributes.
The example in the TMF document shows, that the value {"description":"CPE Output"} should be merged (what kind of merge? JSON merge patch?) with the existing attributes of the "attachment" leading to the result:

...
"attachment": [
{
"id":"2384..",
"attachmentType": "screenshot",
"description":"CPE Output",
"mimeType": "image/png",
"name": "CPE Diagnostic Output",
"url": "https://mycsp.com/docloader?docnum=3534555",
"@type": "AttachmentRef"
}
],
...

Is this the intended behavior?
Is the work still ongoing?
Is it possible to contribute somehow?

Bert regards,
Bernhard

Hi Bernhard

The Design Guideline V5 are currently still being worked on.  Would be great to have your input on Part5.  Most of the discussions are on github here...
GitHub · Where software is built

You will first need to join the Open API project at this page... TM Forum - Site Content - Page - Collaboration projects

Best wishes

Dan.

Dear community,

I am working an standards for our TMF API implementations and try setup guidelines for resource upate operations (PUT & PATCH).
Combining JSONPath with JSON Patch looks like a very promissing approach, keeping in mind, that the surrounding standards (RFC9535, ...) and frameworks are still evolving.

Initially I was looking for the equivalent of the "[-]" indexing of JSON Pointer to append elements to a list when I stumbled across several questions. I only refer to the JSONPath examples in TMF630 Part5 v5.0.0. The version v4.0.0/v4.2.0 shows similar challanges.

1.) The "add" operation, TMF630 v5.0.0 Part5, "5.1.1. Using JSON Path":

This chapter shows three examples, the first one is clear:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')].description", "value":"CPE Output" } ]

The path evaluates to the (not existing) element "description" of the "attachment" with id='2384..'. In this case, the the behavior of "add" as of RFC6902 is clear. Add the element 'description' and assign the value 'CPE Output'. The TMF document is consistent with the descriptions in TMF6902 here.

The second example confuses me and seems not to fit to the descriptions in RFC6902:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')]", "value": {"description":"CPE Output"} } ]

Well, the path evaluates to the element "attachment" with id='2384..'. TMF6902 describes the bahavior of "add" clearly:

If the target location specifies an object member that does exist,that member's value is replaced.

In other words, the "attachment" with id='2384..' would get the value {"description":"CPE Output"}, and lose its 'id' and all other attributes.
The example in the TMF document shows, that the value {"description":"CPE Output"} should be merged (what kind of merge? JSON merge patch?) with the existing attributes of the "attachment" leading to the result:

...
"attachment": [
{
"id":"2384..",
"attachmentType": "screenshot",
"description":"CPE Output",
"mimeType": "image/png",
"name": "CPE Diagnostic Output",
"url": "https://mycsp.com/docloader?docnum=3534555",
"@type": "AttachmentRef"
}
],
...

Is this the intended behavior?
Is the work still ongoing?
Is it possible to contribute somehow?

Bert regards,
Bernhard

Hello Dan,

thank you for the update. I'll be joining the project and the discussions inside the project.

Regards,

Bernhard

Hi Bernhard

The Design Guideline V5 are currently still being worked on.  Would be great to have your input on Part5.  Most of the discussions are on github here...
GitHub · Where software is built

You will first need to join the Open API project at this page... TM Forum - Site Content - Page - Collaboration projects

Best wishes

Dan.

Dear community,

I am working an standards for our TMF API implementations and try setup guidelines for resource upate operations (PUT & PATCH).
Combining JSONPath with JSON Patch looks like a very promissing approach, keeping in mind, that the surrounding standards (RFC9535, ...) and frameworks are still evolving.

Initially I was looking for the equivalent of the "[-]" indexing of JSON Pointer to append elements to a list when I stumbled across several questions. I only refer to the JSONPath examples in TMF630 Part5 v5.0.0. The version v4.0.0/v4.2.0 shows similar challanges.

1.) The "add" operation, TMF630 v5.0.0 Part5, "5.1.1. Using JSON Path":

This chapter shows three examples, the first one is clear:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')].description", "value":"CPE Output" } ]

The path evaluates to the (not existing) element "description" of the "attachment" with id='2384..'. In this case, the the behavior of "add" as of RFC6902 is clear. Add the element 'description' and assign the value 'CPE Output'. The TMF document is consistent with the descriptions in TMF6902 here.

The second example confuses me and seems not to fit to the descriptions in RFC6902:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')]", "value": {"description":"CPE Output"} } ]

Well, the path evaluates to the element "attachment" with id='2384..'. TMF6902 describes the bahavior of "add" clearly:

If the target location specifies an object member that does exist,that member's value is replaced.

In other words, the "attachment" with id='2384..' would get the value {"description":"CPE Output"}, and lose its 'id' and all other attributes.
The example in the TMF document shows, that the value {"description":"CPE Output"} should be merged (what kind of merge? JSON merge patch?) with the existing attributes of the "attachment" leading to the result:

...
"attachment": [
{
"id":"2384..",
"attachmentType": "screenshot",
"description":"CPE Output",
"mimeType": "image/png",
"name": "CPE Diagnostic Output",
"url": "https://mycsp.com/docloader?docnum=3534555",
"@type": "AttachmentRef"
}
],
...

Is this the intended behavior?
Is the work still ongoing?
Is it possible to contribute somehow?

Bert regards,
Bernhard

Hello Bernhard,

thank you for pointing this issues out.

Did you provide some more input on this?
Next week, there will be the API Spec Jam in London where I can work in these issues.

Regards,

Lutz

Hello Dan,

thank you for the update. I'll be joining the project and the discussions inside the project.

Regards,

Bernhard

Hi Bernhard

The Design Guideline V5 are currently still being worked on.  Would be great to have your input on Part5.  Most of the discussions are on github here...
GitHub · Where software is built

You will first need to join the Open API project at this page... TM Forum - Site Content - Page - Collaboration projects

Best wishes

Dan.

Dear community,

I am working an standards for our TMF API implementations and try setup guidelines for resource upate operations (PUT & PATCH).
Combining JSONPath with JSON Patch looks like a very promissing approach, keeping in mind, that the surrounding standards (RFC9535, ...) and frameworks are still evolving.

Initially I was looking for the equivalent of the "[-]" indexing of JSON Pointer to append elements to a list when I stumbled across several questions. I only refer to the JSONPath examples in TMF630 Part5 v5.0.0. The version v4.0.0/v4.2.0 shows similar challanges.

1.) The "add" operation, TMF630 v5.0.0 Part5, "5.1.1. Using JSON Path":

This chapter shows three examples, the first one is clear:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')].description", "value":"CPE Output" } ]

The path evaluates to the (not existing) element "description" of the "attachment" with id='2384..'. In this case, the the behavior of "add" as of RFC6902 is clear. Add the element 'description' and assign the value 'CPE Output'. The TMF document is consistent with the descriptions in TMF6902 here.

The second example confuses me and seems not to fit to the descriptions in RFC6902:

[ { "op": "add", "path": "$.attachment[?(@.id=='2384..')]", "value": {"description":"CPE Output"} } ]

Well, the path evaluates to the element "attachment" with id='2384..'. TMF6902 describes the bahavior of "add" clearly:

If the target location specifies an object member that does exist,that member's value is replaced.

In other words, the "attachment" with id='2384..' would get the value {"description":"CPE Output"}, and lose its 'id' and all other attributes.
The example in the TMF document shows, that the value {"description":"CPE Output"} should be merged (what kind of merge? JSON merge patch?) with the existing attributes of the "attachment" leading to the result:

...
"attachment": [
{
"id":"2384..",
"attachmentType": "screenshot",
"description":"CPE Output",
"mimeType": "image/png",
"name": "CPE Diagnostic Output",
"url": "https://mycsp.com/docloader?docnum=3534555",
"@type": "AttachmentRef"
}
],
...

Is this the intended behavior?
Is the work still ongoing?
Is it possible to contribute somehow?

Bert regards,
Bernhard