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

[Anders Rundgren <[e-mail]>]

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
>