Support JSONPath in AttributeSelector

[cdanger]

Proposal: add an optional attribute contentType in AttributeSelector, with two possible values: XML (default value) and JSON.
If contentType = JSON, the <Content> must be processed as JSON object instead of XML, and the Path handled as JsonPath according to the JSONPath RFC 5935, still in draft currently now an IETF Proposed Standard.

This is consistent with the JSON Profile.

[cdanger]

Good news: the JSONPath RFC draft has been finalized and promoted to an IETF Proposed Standard: RFC 5935 (Feb. 2024)!

IETF Proposed standard (RFC 2026): A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. [...]

[cdanger]

If we follow #33 logic, it should not go in the core spec but in a separate profile dedicated to JSON data processing.

[humantypo]

Personally I’m interested in exploring the idea of policies being expressed in either XML or JSON—which, in my mind, requires JSON be “promoted” to Core level incorporation (and ostensibly, the JSON Profile no longer be needed).

[steven-legg]

Personally I’m interested in exploring the idea of policies being expressed in either XML or JSON—which, in my mind, requires JSON be “promoted” to Core level incorporation (and ostensibly, the JSON Profile no longer be needed).

@humantypo , Cyril is talking about moving the optional, path-related definitions to separate profiles regardless of format. It is a separate consideration to what format has prominence in the core specification for policy representation.

A separate XPath profile would still need XSD and/or JSON Schema definitions, as would a separate JSONPath profile.