Fork me on GitHub
Ben Sless16:06:47

@valtteri moving discussion of malli here, regarding json schema, the first item we should tackle, and hardest, IMO, is time schemas. There was a PR I opened and a long thread on it in the issues. It seems like the biggest tension there is good-enough vs. specification compliance How do you want to handle it?


for cljs I would vote for (what tick uses) but how do you deal with this now being a dependency of malli?


Hmmm personally I’d like to minimize dependencies


I think the java.time stuff looks good and in CLJS we could perhaps just use js dates (I know, they’re bad) or


We can always make initial release under malli.experimental.something so we can move on and get feedback


how about a code path branch using dynaload? - one set of schemas backed by js dates and one by js-joda (


And if it’s a decision between “good enough” and “specification compliance” this one leans to “good enough”


but yea not a big deal because a date lib can always be added in user-space

👍 1

Would these be realistic goals? • good and practical defaults for Java • “good enough” defaults for JS • no new deps With a quick glance Ben’s suggestion for the java impl looks good and practical to me. I’ll promise to read through all the linked references tonight.

Ben Sless17:06:42

Thanks I'd also try getting feedback from Henry, both on our current options and maybe on a path forwards, how we could reach full spec compliance while delivering something that covers 99% of use cases in the meanwhile


Oh, so you have a hard requirement for the full spec compliance?


I think we anyway want to have extension points so that the behaviour can be customized.


But have defaults that work for the 99%

Ben Sless18:06:39

With an eye towards an end goal of using json schema or async api across an organization, with a variety of languages, I want to at least have parity in features

Colin P. Hill13:06:46

Unsure if this is in the scope of your discussion, but I'm currently working on an effort that uses the support Malli has for this so far, and besides a lack of built-in support for types beyond date-time, the other pain point I've been running into for time types is that the generated JSON schemas are less restrictive than the Malli schemas they're based on. A uuid? in Malli becomes a value with a string with a format of date-time in JSON – but JSON Schema validators are not required to treat formats as normative. This means another system could consume the JSON Schema output to validate a message, pass the message to the system using Malli, and then have it rejected as invalid. My workaround has been manually adding a pattern field.


I've been thinking this and one way to circumvent the date/time type problem could be to treat them as strings. There could be a regex schema according to the format in JSON-schema. Dunno if this would make any sense though. But this is how it works in JSON-schema.


I've read through all the earlier conversations and checked a couple of different JSON schema implementations how they do it. I think I'm more confused now than in the beginning. 😄

Ben Sless17:06:30

We could always ask in their slack


Yeah. But what do you think @UK0810AQ2 if in JSON-schema temporal types are strings with some enforced format.. would it make sense to do it in the same way on malli side?


So we could be compliant and move on 😉


Another thing we should clarify is that which version(s) of the JSON-schema spec are we targeting to support


We can also try to not solve the malli temporal schemas in general but make json-schema specific variants. If this would help us to move on

Ben Sless19:06:51

Thing is, in malli you can accept strings and make sure they transform to timestamps. When they leave the system they'll be serialized back to strings anyway

Ben Sless19:06:02

The temporal thing has become my bugbear


Yeah I understand that but I was thinking since timestamps are the “blocker” because there are so many possible ways to do them and it's difficult to make it good for both java and js, we could try to avoid those decisions. Java side is more clear to me. We could also think “java first and js some day”.


If we think only Java and assume your suggestion about the types, there are no blockers…right? :thinking_face:

Ben Sless19:06:24

Not from me, Tommi or Henry might have reservations we should account for


I think we could whip up a working example to make it concrete. I guess the types can easily be changed if better suggestions pop up


I mean a working example in context of json schema


It's easier to get that feedback when people can see it in action


Oh man, I just noticed that the old json-schema->malli PR is actually alive again!


I don’t understand how I had missed that. I’ll comment to the PR that we’re thinking about these same things here. Dunno if is in this Slack?