JSON Path spec version update in xAPI profiles structure document

[imartinezortiz]

Filing an issue about the xAPI Profiles specification? Please include the following

• Which part/parts of the specification are at issue?

xAPI profiles structure: statements templates

• What is your understanding of what the spec means in these parts?

Currently this document references a de-facto JSON path specification documentation, but currently there is an ongoing IETF effort https://datatracker.ietf.org/wg/jsonpath/about/ to create an IETF standard for JSON Path and align it with other IETF efforts.

• Related to your implementation, what's the use case you're trying to achieve? What are the user stories you're trying to support?

As the IETF about page for the JSON Path WG states, there is some variability in the implementation of the JSON Path specification, having a direct impact in a xAPI profile processor library.

• How you would like the specification to be improved?

I suggest to track the IETF JSON Path WG progress as part of the IEEE P9274.2.1 WG work, and evaluate the impact in the xapi profile spec update process.

[andyjohnson]

@andyjohnson will make a PR for this change in document to modify/include guidance and resources.

[imartinezortiz]

Opened #260 to address this issue.

[imartinezortiz]

Just doing some maintenance on pending issues.

Seems that the IETF WG is progressing. In fact, the WG seems to be working on two separate specs (I-Reg and JSONPath base) in order to address some of the security concerns of using some parts of the JSONPath spec (in filters and expressions that are currently forbidden in the xAPI profiles spec).

In addition as discussed in one of our subgroup meeting I raised and issue related to the following xapi profiles structure section related to JSONPath:

Any two or more legal JSONPath expressions, joined together by the pipe character |, optionally with whitespace around the pipe, are also considered a legal JSONPath expression. The value of this expression is all the values returned by each expression individually, flattened (that is, if one expression returns N values and another returns a single value, the combination returns N+1 values, not two values).

This constraint is an extension to the JSONPath syntax, so the profile server and processing libraries require to split the JSONPath expression in order to validate / apply it. A more granular approach would be to change the attributes that use JSONPath expressions from string to Array types.

[imartinezortiz]

Quick update and reminder for the WG meetings, since Feb 2024 RFC 9535 is as a proposed standard.