Re: [Jsonpath] [ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath] A "General Considerations" section (#58)

["Martin J. Dürst" <[e-mail]>]

On 09/03/2021 16:47, Greg Dennis wrote:
> This formatting (or lack thereof) removes all cues as to what's the Schema spec text vs my comments vs your comments.
> Greg

Hello Greg,

In the messages from Carsten, I can easily see the distinction. In 
messages from you, either things are reversed (your new comments look 
like cited text whereas all the cited text looks like it's newly written 
text) or there's no distinction at all.

You probably have more of a clue as to why that happens than me. I have 
seen other IETF participants with various similar issues, but not 
something exactly like you. What Carsten's mailer does is what I see 
most other mailers in IETF discussions do.

I hope you can fix the issues on your side soon.

Regards,   Martin.

P.S.: I'm using Thunderbird.


>   
>    On Tue, 9 Mar 2021 at 8:40 pm, Carsten Bormann<[e-mail]> wrote:   Moving this discussion to the list, because it touches a large number of issues.
> I’ll try to parse apart this pile of unrelated considerations; maybe we can dispatch them into the specific issues raised.
> 
> 
> 6.1. Range of JSON Values
> 
> An instance may be any valid JSON value as defined by JSON. JSON Schema imposes no restrictions on type: JSON Schema can describe any JSON value, including, for example, null.
> 
> 
> JSON Schema uses the word "instance" to describe the JSON data that's being validated. We seem to have landed on the word "data." Regardless, I think the gist of this also holds true for JSON Path: input values can be of any JSON type (although only certain types may return results depending on the Path)
> 
> Yes, JSONpath should be able to be applied to any JSON data item (JSON value).If we haven’t said so yet, that’s probably because it is an obvious property of a useful query language…(Editorial, if you ask me.)
> 
> 
> 
> 6.2. Programming Language Independence
> 
> JSON Schema is programming language agnostic, and supports the full range of values described in the data model. Be aware, however, that some languages and JSON parsers may not be able to represent in memory the full range of values describable by JSON.
> 
> 
> This, I think, is of utmost importance. We definitely should not favor a specific language. Doing so would inhibit inclusivity and shun people who work in incompatible frameworks.
> 
> There is a wide gamut of meanings to the expression “favor a specific language”.Is requiring arbitrary precision integers “favoring a specific language”?  Specifying a specific regex dialect?We may need to accept the dominance of certain platforms in our decisions (e.g., the I-JSON limitations caused by JavaScript), so I don’t know how to act on this.
> Of course, we shouldn’t wholesale import a language (e.g., as the expression language), except if we do.
> 
> 
> This statement also makes it clear that it's understood that some frameworks inherently have limitations that may prevent them from being able to implement the full expression of JSON Schema. Declaring this outright allows such frameworks to have partial "best effort" implementations and still be compliant with the specification.
> 
> We probably want to avoid compliance levels, profile implementation conformance statements…Just as we need “extension points” (see below), we may need “limitation points”.
> 
> 
> 
> 6.3. Mathematical Integers
> 
> Some programming languages and parsers use different internal representations for floating point numbers than they do for integers.
> 
> For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional part.
> 
> 
> I'm not sure whether this would apply for us, except maybe for array indices.
> 
> No idea what this does here.  We don’t get to decide how our JSON input is encoded.More importantly, we don’t get to see that (unless we require JSONpath to be used only with a specialty not-quite-JSON decoder!).
> (But, indeed, we do get to decide the number system used in our expression language.)
> 
> 
> 
> 6.4. Regular Expressions
> 
> Keywords MAY use regular expressions to express constraints, or constrain the instance value to be a regular expression. These regular expressions SHOULD be valid according to the regular expression dialect described in ECMA-262, section 21.2.1.
> 
> Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide Unicode support, or processed in such a way which provides Unicode support as defined by ECMA-262.
> 
> Furthermore, given the high disparity in regular expression constructs support, schema authors SHOULD limit themselves to the following regular expression tokens:
>     
>     - individual Unicode characters, as defined by the JSON specification;
>     - simple character classes ([abc]), range character classes ([a-z]);
>     - complemented character classes ([^abc], [^a-z]);
>     - simple quantifiers: "+" (one or more), "" (zero or more), "?" (zero or one), and their lazy versions ("+?", "?", "??");
>     - range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at most y, occurrences), {x,} (x occurrences or more), and their lazy versions;
>     - the beginning-of-input ("^") and end-of-input ("$") anchors;
>     - simple grouping ("(...)") and alternation ("|").
>     - Finally, implementations MUST NOT take regular expressions to be anchored, neither at the beginning nor at the end. This means, for instance, the pattern "es" matches "expression".
> 
> 
> Not sure if we're planning on supporting regular expressions. It appears that some implementations do have some support, but it's all extension on the original syntax at this point. Still, this is a good declaration of support.
> 
> As we define our own expression language, we also get to define our own regular expression dialect (I hope in a less mushy way than above).
> 
> 
> It also ties in closely to section 6.2 regarding framework limitations as not all frameworks support the same flavor of regular expression syntax.
> 
> It may be worthwhile to quell outright the expectation that the JSONpath regexes can just be dumped into the implementation regex dialect.
> 
> 
> 
> 6.5. Extending JSON Schema
> 
> Additional schema keywords and schema vocabularies MAY be defined by any entity. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords and vocabularies to be supported by implementations that do not explicitly document such support. Implementations SHOULD treat keywords they do not support as annotations, where the value of the keyword is the value of the annotation.
> 
> Implementations MAY provide the ability to register or load handlers for vocabularies that they do not support directly. The exact mechanism for registering and implementing such handlers is implementation-dependent.
> 
> 
> This is good to have because invariably, implementations will want to extend functionality beyond what's in the spec. It basically covers other implementations from also having to provide the same extensions, requiring only what is stated in the spec.
> 
> It also mentions "vocabularies," which are a spec-defined mechanism by which implementation can extend functionality via new keywords in such a way that they can optionally be supported in other implementations. Furthermore, this mechanism allows the other implementations to refuse to process a schema that requires a given vocabulary if the implementation doesn't understand it. This bit I think is good for later when we eventually get to spec-defined extension mechanisms, but I don't expect that'll be in the first draft.
> 
> 
> Yes, we need an extensibility (and evolvability) story.This will revolve around extension points, which need to be defined in a more rigorous way than “ignore what you don’t understand”.We may also decide not to have extension points (like JSON did), but we need to make this decision in a very conscious way.
> Grüße, Carsten
> 
>