On Wed, Jul 26, 2023 at 4:07 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote:
> > > >> * Section 3 should probably specify what should happen if the JSONpath >> refers to an attribute/value that's not present in the object it's >> referencing. >> >> [ML] The JSONPath expressions related to reverse search properties are >> provided by servers and have been previously registered with IANA, hence >> they have been checked by Designated Experts. It's very unlikely they are >> wrong. Can't imagine how clients can operate when servers provide wrong >> information. I mean, servers can return an error code when clients include >> wrong or unsupported reverse search properties in thei requests, but >> servers are always expected to provide correct data. >> > > It just feels strange to presume you will always have valid input and > never discuss error condition handling. I'm still learning about JSONpath > (it's also in "AD Evaluation") so maybe this is a teachable moment for me, > but it seems like there's a presumption that a query will always be run > against a value that will resolve; is that the case here too? Maybe we > should say that if so. > > [ML] Probably I didn't make myself clear or I still don't catch your > remark. The JSONPath expressions are provided by servers to help clients in > linking the available reverse search properties to the reponse fields. > Client can only use the reverse search properties in their queries. The > invalid use of both reverse search poperties and predicates by clients > results in servers returning an error as defined in Section 7: > Now that I'm done with my review of JSONpath and got that WG to explain this to me, you can ignore my suggestion. JSONpath, if you run it on a value that doesn't include what you're trying to "path" to, just returns an empty result with no error. Since you're building on top of that, that's also what you get. Therefore, as long as your specification can handle an empty JSONpath result *or* you say explicitly that your specification is based on the assumption that that'll never happen, then there's not much you need to say, and we're good here. > IMO, the document already covers those cases. Hence, no further change is > needed about this matter. > > Do you agree ? > Yup. Let's go. Is the current version ready or do you need one more after this review? -MSK
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
