Re: [Json] JSON Schema Language: extensibility and unspecified properties

[Ulysse Carion <[e-mail]>]

> How can you express this in a main schema using JCL?

I'm not entirely sure I follow your description. Could you illustrate
it with some example JSON values? I'm also a bit unclear on your
requirements for the "main schema", and how it fits with requirements
around "unspecified properties".

On Sat, Aug 10, 2019 at 12:00 PM Anders Rundgren
<[e-mail]> wrote:
>
> If we stick to unspecified properties I'm currently working with a
> payment authorization scheme where some components will be defined
> by the payment networks.  The components start with a defined property
> holding a JSON Object but the contents of the object is not known by
> the "main" schema.
>
> In my programmatic solution the "main schema" ignores such components
> and only validates that they conform JSON.  The components are
> then dealt with by customer supplied decoders which indeed may use
> a schema.
>
> How can you express this in a main schema using JCL?
>
> Anders
>
>    paymentRequest = new PaymentRequest(rd.getObject(PAYMENT_REQUEST_JSON));
>    undecodedPaymentMethodSpecific = rd.getObject(BACKEND_METHOD_SPECIFIC_JSON);
>    rd.scanAway(BACKEND_METHOD_SPECIFIC_JSON);
>    referenceId = rd.getString(REFERENCE_ID_JSON);
>
>
> On 2019-08-10 03:43, Ulysse Carion wrote:
> > Hi folks,
> >
> > Thanks again for all the wonderful suggestions for JSON Schema
> > Language. I've just published a new draft incorporating suggestions
> > from the last update. You can read it here:
> >
> > https://tools.ietf.org/html/draft-ucarion-json-schema-language-02
> >
> > I would like advice on the two following changes I've made to the spec.
> >
> > First, I added explicit discussion of how JSL can be extended. The
> > language is at the end of section 2, but I'll reproduce it here:
> >
> >> This document does not describe any extension mechanisms for JSL schema
> >> validation. However, schemas (through the `non-keyword` CDDL rule in this
> >> section) are defined to allow members whose names are not equal to any of the
> >> specially-defined keywords (i.e. `definitions`, `elements`, etc.) described in
> >> this section. Call these members "non-keyword members".
> >>
> >> Users MAY add additional, non-keyword members to JSL schemas to convey
> >> information that is not pertinent to validation. For example, such non-keyword
> >> members could provide hints to code generators, or trigger some special behavior
> >> for a library that generates user interfaces from schemas.
> >>
> >> Users SHOULD NOT expect non-keyword members to be understood by other parties.
> >> As a result, if consistent validation with other parties is a requirement, users
> >> SHOULD NOT use non-keyword members to affect how schema validation, as described
> >> in {{semantics}}, works.
> >
> > Basically, my stance is: you can add custom stuff to schemas, but you
> > can't change validation. I expect that people will change validation
> > anyway, but they're not going to expect portability. I don't feel that
> > adding some sort of registry of keywords / forms is valuable yet.
> > Perhaps something like that can be in whatever replaces JSL?
> >
> > How do folks feel about this? Does anyone have suggestions on better
> > ways I can approach extensibility, or how I should phrase this
> > language?
> >
> > The other thing I want advice on is "strict" mode, called "strict
> > instance semantics" in the spec. Basically, strict instance semantics
> > about whether it's ok to send "extra"/"unknown"/"unspecified"
> > properties in an object.
> >
> > Right now, validation behavior is specified as a single, top-level
> > "strict": true/false (default is "true") property. You can't mix and
> > match strict and non-strict. But Carsten off-list noted that might be
> > a bit "blunt". Do others agree?
> >
> > The context for my decision is that two of major typed languages used
> > in industry, Java and Golang, don't typically support mixing and
> > matching. Go just as a blunt DisallowUnknownFields:
> >
> > https://golang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields
> >
> > And Java's Jackson has a FAIL_ON_UNKNOWN_PROPERTIES:
> >
> > http://fasterxml.github.io/jackson-databind/javadoc/2.9/com/fasterxml/jackson/databind/DeserializationFeature.html#FAIL_ON_UNKNOWN_PROPERTIES
> >
> > Both are all or nothing.
> >
> > Also, there is the question of whether "strict" is a good name for
> > this property in schemas. Is there a better name for it? "strict" can
> > be understood in many ways. Open to ideas here as well.
> >
> > Other changes:
> >
> > - Removed int64/uint64 (and removed discussion related to I-JSON)
> > - Clarified that 1.0e1 is an integer
> >
> > Finally, I've moved JSL to a desired status of "Informative", and I'll
> > be going through the independent stream once the discussion here
> > appears to have settled.
> >
> > Thanks again for all the help,
> > Ulysse
> >
> > _______________________________________________
> > json mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/json
> >
>