lyd_new_path handle json encoded string leaves

[irfanHaslanded]

According to ietf rfc 8259, strings are always surrounded by double
quotes. This means, for storing within libyang, we must strip input
data of these, and take the value as the stripped portion.

Example: const char * data = ""Great View""; should yield
const char *value = "Great View";

For this, a new option is used LYD_NEW_PATH_JSON_VALUE

[michalvasko]

Could you please reference the exact text that mentions this feature?

[irfanHaslanded]

Could you please reference the exact text that mentions this feature?

https://datatracker.ietf.org/doc/html/rfc8259#section-7

[7](https://datatracker.ietf.org/doc/html/rfc8259#section-7).  Strings

   The representation of strings is similar to conventions used in the C
   family of programming languages.  A string begins and ends with
   quotation marks.  All Unicode characters may be placed within the
   quotation marks, except for the characters that MUST be escaped:
   quotation mark, reverse solidus, and the control characters (U+0000
   through U+001F).

[michalvasko]

I read that and, to my understanding, it means the quotation marks should be escaped (and I believe they are), not removed.

[irfanHaslanded]

I read that and, to my understanding, it means the quotation marks should be escaped (and I believe they are), not removed.

This change addresses this part of the RFC A string begins and ends with quotation marks.

Normally, lyd_new_path would be passed
char *val = "Great View"

but when decoding from gnmi, we would get
char *val = "\"Great View\""

However, we must consider the value as Great View and not "Great View"

[jktjkt]

What is the use case for feeding libyang with JSON-encoded string values? How is this different from, say, Base64-encoded string values or RFC2047-style encoded string values? How do you plan to use this, and why is it needed to put this feature into libyang?

[michalvasko]

Each string value in JSON is encoded as "value", the quotations are simply a part of the data format and it is expected the parser removes it. Similarly with encoded characters and similar format-specific phenomenons. libyang handles only YANG JSON-specific features such as the interpretation of prefixes.

[irfanHaslanded]

I understand. Will keep this changeset in gnmi where it should belong.