Explain json fix65

[j---]

This should clear the way for addressing #88
Closes #65

Since the JSON is mostly self-documenting, I did not spend a lot of time describing it in the doc.

@sei-vsarvepalli , perhaps the text creates a new issue to make sure the strings in the choices array match the formatting convention described in the text? If we think that is valuable. Open to amendments to the proposed formatting.

[sei-vsarvepalli]

This should clear the way for addressing #88
Closes #65

Since the JSON is mostly self-documenting, I did not spend a lot of time describing it in the doc.

@sei-vsarvepalli , perhaps the text creates a new issue to make sure the strings in the choices array match the formatting convention described in the text? If we think that is valuable. Open to amendments to the proposed formatting.

I am not sure if this text is talking about JSON schema changes or not. If so, the choices becoming colon-delimited seem not necessary or useful They are currently array of key-value pairs in the order of walking through the decision tree key is the decision and value is the choice selected (chosen), i.e., choices[0] is the first decision taken the analyst and so on. We also want to possibly support other languages in decision points and their respective choices for which JSON is well-suited with UTF-8 support. Both human and machine can read these as they are without much complications or additional interpretations.

Lemme know if I am wrong or reading this wrong.

Vijay

[sei-vsarvepalli]

This should clear the way for addressing #88
Closes #65
Since the JSON is mostly self-documenting, I did not spend a lot of time describing it in the doc.
@sei-vsarvepalli , perhaps the text creates a new issue to make sure the strings in the choices array match the formatting convention described in the text? If we think that is valuable. Open to amendments to the proposed formatting.

I am not sure if this text is talking about JSON schema changes or not. If so, the choices becoming colon-delimited seem not necessary or useful They are currently array of key-value pairs in the order of walking through the decision tree key is the decision and value is the choice selected (chosen), i.e., choices[0] is the first decision taken the analyst and so on. We also want to possibly support other languages in decision points and their respective choices for which JSON is well-suited with UTF-8 support. Both human and machine can read these as they are without much complications or additional interpretations.

Lemme know if I am wrong or reading this wrong.

Vijay

Ha,

I think you may be talking about the computed short form representation! Sorry I may have confused myself.. Will review once again.

[j---]

They are currently array of key-value pairs in the order of walking through the decision tree key is the decision and value is the choice selected (chosen), i.e., choices[0] is the first decision taken the analyst and so on.

The array elements of choices right now are just a single string. So there is no structured way to say what the decision point was and what value was selected for that decision point. It's flexible right now, which is good. But it needs to be structured in such a way that the value is tied to the decision point name.

I think right now the following array examples would both be valid?

['exploitation','poc','utility','laborious']
['exploitation','utility','laborious','poc']

If we go with ['exploitation:poc','utility:laborious'] then we can enforce the value following the decision point.
There are other ways we could enforce this. For example, choices could be an array of 2-element arrays, both elements being strings.
If I'm wrong and this structure is currently enforced by the schema, please describe how so we can put it in the doc.
Thanks!

[j---]

a607735 resolves the confusion about the JSON description I was having / Vijay noted.

[sei-vsarvepalli]

see also #65 where there are a number of enhancements that needs to be addressed. I will work of the schema updates to ensure we are tracking these.

[j---]

see also #65 where there are a number of enhancements that needs to be addressed. I will work of the schema updates to ensure we are tracking these.

Since those will be handled under #106, does that mean this PR can be approved and merged?