Re: [auth48] AUTH48: RFC-to-be 9535 <draft-ietf-jsonpath-base-21> for your review

[Stefan Gössner <[e-mail]>]

I'm fine with anything here, except a single bit below ...


Am 02.02.2024 um 13:50 schrieb Carsten Bormann:
> Hi Alanna,
>
> thank you for the quick update.
> For now, we’ll first respond specifically to your follow-up questions/comments.
>
>> On 2024-02-02, at 02:41, Alanna Paloma<[e-mail]>  wrote:
>>
>> Hi Carsten,
>>
>> Thank you for your replies. We have updated the document accordingly. Please note that we have a few follow-up questions/comments.
>>
>>>> 15) <!--[rfced] For clarity, may we update this list item as follows?
>>>>
>>>> Original:
>>>> -  numbers at least one of which is not expected to interoperate
>>>>   as per I-JSON, where the numbers compare equal using an
>>>>   implementation specific equality,
>>>>
>>>> Perhaps:
>>>> -  numbers that compare equally using an implementation-specific
>>>>   equality, where at least one is not expected to
>>>>   interoperate as per I-JSON,
>>>> -->
>>> This item is parallel to the one preceding it; this change loses this useful structure.
>> To clarify the text while maintaining the parallel structure, may we update with one of the suggestions listed below?
>>
>> Perhaps A:
>>      -  numbers, where at least one is not expected to interoperate
>>         as per I-JSON, that compare equally using an
>>         implementation-specific equality,
>>
>> Perhaps B:
>>      -  numbers, at least one of which is not expected to interoperate
>>         as per I-JSON, where the numbers compare equally using an
>>         implementation-specific equality,
> “compare equal” is a term of art (compare with the result that they are equal), compare equally does not quite make sense in this context.
> So the change reduces to adding a comma, which probably can be done, even if strictly speaking this changes the relative clause to a non-defining one when a defining one is actually meant (this will be clear from the context).
>
> NEW:
>      -  numbers, at least one of which is not expected to interoperate
>         as per I-JSON, where the numbers compare equal using an
>         implementation-specific equality,
>
>>>> 21) <!-- [rfced] Please review "a lightweight/limited, and a more heavyweight
>>>> syntax". Is the syntax both lightweight and heavyweight? Or is another
>>>> meaning intended?
>>>> Original:
>>>> JSONPath expressions move further down the hierarchy using _dot
>>>> notation_ ($.store.book[0].title) or the _bracket notation_
>>>> ($['store']['book'][0]['title']), a lightweight/limited, and a more
>>>> heavyweight syntax replacing XPath's / within query expressions.
>>>> -->
>>> This needs a “respectively”.  The dot syntax is lightweight, but limited, while the bracket syntax is more heavyweight.
>> We have updated the text per your suggestion.
>>
>> Current:
>>   JSONPath expressions move further down the hierarchy using _dot
>>   notation_ ($.store.book[0].title) or the _bracket notation_
>>   ($['store']['book'][0]['title']), a lightweight/limited syntax
>>   and a more heavyweight syntax, respectively, replacing XPath's /
>>   within query expressions.
>>
>> However, to improve readability, may the sentence be further updated as follows?
>>
>> Perhaps:
>>   JSONPath expressions move further down the hierarchy using _dot
>>   notation_ ($.store.book[0].title) or the _bracket notation_
>>   ($['store']['book'][0]['title’]); both replace XPath's / within query expressions,
>>   but _dot notation_ is a lightweight/limited syntax while _bracket notation_
>>   is a more heavyweight syntax.
> I don’t see a need for a “but” for the whole subclause, but could use one for the slash, so maybe:
>
> Suggestion:
>   JSONPath expressions move further down the hierarchy using _dot
>   notation_ ($.store.book[0].title) or the _bracket notation_
>   ($['store']['book'][0]['title’]); both replace XPath's / within query expressions,
>   where _dot notation_ serves as a lightweight but limited syntax while _bracket notation_
>   is a more heavyweight syntax.

Suggestion:

... where _dot notation_ serves as a lightweight but limited syntax while _bracket notation_
  is a more heavyweight but unlimited (general) syntax.


>>>> 23) <!-- [rfced] We see type="JSONPath" is used for some of the sourcecode elements
>>>> in this document. This is not included in our current list of preferred
>>>> values; seehttps://www.rfc-editor.org/materials/sourcecode-types.txt.
>>>> Please review the list and let us know which value to use for "type".
>>>>
>>>> If the current list does not contain an applicable type, feel free to suggest
>>>> additions for consideration. Note that it is also acceptable to leave the
>>>> "type" attribute not set.
>>>> -->
>>> One of us believes the sourcecode-type should be application/jsonpath.
>>> But as long as we don’t use media-type names, we probably should shorten this to jsonpath.
>>> (§ 3.1 does not suggest a filename extension, which would be a natural candidate.  JSONPath is uncharacteristically mixed case, and “jsonpath” (lower case) is closest to what has been done to other sourcecode-types.)
>> We have sent a request to the RFC Production Advisory Team (RPAT) about adding “jsonpath" to the list of preferred values. See<https://mailarchive.ietf.org/arch/msg/rpat/vVTLmBBHHMnL_tLf-p-QbwEHyHM/>.
>>
>> For now, we have updated to use type=“jsonpath” and will update further depending on the outcome of the RPAT discussion.
> Good, thank you!
>
> One more observation:
>
>>> Given that we no longer have good information about this example, we think we can simplify this to:
>>>
>>>> The books example was taken from course material that University Bielefeld, Germany used in 2002.
> I looked uphttps://www.uni-bielefeld.de/  only now, and I notice that the university styles itself “Bielefeld University” in English, which we should follow (the German name is “Universität Bielefeld”, which led to my mistake).
>
> Grüße, Carsten