search

adlnet / xapi-profiles

A set of documents addressing the structure of and supporting services for xAPI Profiles.
https://adlnet.gov/projects/xapi/
Apache License 2.0
54 stars 27 forks source link

JSON Path spec version update in xAPI profiles structure document #257

Open imartinezortiz opened 2 years ago

imartinezortiz commented 2 years ago

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

xAPI profiles structure: statements templates

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.

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.

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 commented 2 years ago

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

imartinezortiz commented 2 years ago

Opened #260 to address this issue.

imartinezortiz commented 1 year ago

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 commented 1 month ago

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