I realize that people need to make decisions based on their personal experience, and I don’t have a good rule-of-thumb for when to try a variation of a “bad” idea.

For people who've spent a lot of time with ANT, you might be familiar with this article from its creator: https://web.archive.org/web/20041217023752///x180.net/Journa...

It was possible and even made sense to use XML as the format for a build tool, however, it got stretched way to far. The idea was applied in use cases that were less and less appropraite, as a result years later you end up with something that is unwieldy and doesn't make sense and, generally, thought of as "terrible".

There are use cases were JsonLogic might make a lot of sense, and for those that is great.

Generally, I'm sceptical as there is high risk of increasing couplings in a way that will make change much harder. This will be particularly true if it is applied to use cases that don't truly warrent this kind of solution.

If that power user is properly skilled, authorized and authenticated, why not give them a read-only connection to the DB and let them write their own SQL?

How many times has the UI been nothing but an impediment?

There are people who actually use JSON for markup... the resulting schemas are usually very bad, and they disappear quickly without even gaining fraction.

When used properly -- XML for markup, JSON for serialization -- each format is pretty nice, and will probably last forever.

To answer your question, what you have is (effectively) code, and just use a programming language for this, call it a function, give it a name, arguments, test suite and register it as a plugin to your platform. Oh, and documentation, change history, etc.

Seriously - the "overhead" more than pays for itself when 100 other yahoos do this nonsense and you end up with data files containing untestable code that breaks when combined with other code, breaks when the platform is changed, etc etc

With all due respect, you're making a classic mistake: presenting the solution to a problem without tracing the problem back to the use case.

Why do you need to include the logic matrix in the schema? I can promise you that the real world use cases where you'd need to this are virtually non-existent. You wouldn't even do this for some extreme case like Mars rover software.

Your business logic should have a single source of truth. The vast majority of the time you can just write an API for other software to synchronize with.

Otherwise just ship new builds of your software package to the client instead of a new schema. If you need to be modular then use modular primitives such as shared libraries.

Again, there's virtually no real world scenario where you need to ship a logic schema (in any format) to a client. You might as well ship a shared library, importable module, a completely new binary, etc, etc.

Here is the thing...There is already a crappy way to describe JSON Schemas[1,2].

It is hard to grok by visual inspection and expressing conditions like "this element can either be a list containing a subset of these values or a hash with keys that belong to the same set" etc make it unwieldy.

The schema ends up being really brittle and hard to modify. 100% green-lit test coverage don't mean a thing when it is soooo easy to end up with a false negative.

Now take that and add logic to it? One has to question the existence of all the programming languages in use if we are going to end up subjecting ourselves to that torture.

[1]: https://json-schema.org/ [2]: https://json-schema.org/draft/2020-12/json-schema-core.html

You could also think about Dhall as a front-end. You could represent the whole credential as a union type. This isn't deeply thought out, but this should give an idea as to how this would look:

    let TestResult = < Positive | Negative >

    let ScreeningTestDetails =
          { hasTestResult : Bool, testResult : TestResult, testTime : Natural }

    let CredentialData =
          < Vaccinated | RapidSarsCov2PCRTest : ScreeningTestDetails >

    let Credential =
          { credentialName : Text
          , credentialIssuer : Text
          , credentialData : CredentialData
          }

    let result
        : Credential
        = { credentialName = "COVID-19 Back to Work Credential"
          , credentialIssuer = "Acme Labs Inc."
          , credentialData = CredentialData.Vaccinated
          }

    let result2
        : Credential
        = { credentialName = "COVID-19 Back to Work Credential"
          , credentialIssuer = "Acme Labs Inc."
          , credentialData =
              CredentialData.RapidSarsCov2PCRTest
                { hasTestResult = True
                , testResult = TestResult.Negative
                , testTime = 1622145851
                }
          }

     let prop0 =
      λ(x : ScreeningTestDetails) →
        assert : greaterThan x.testTime 1522145851 ≡ True


    in  result2

Edit: added an assertion to model the 72 hour requirement.

This strikes me as nice:

    (parsing-matrix
     (if (or (= (var "credentialData" "rapidSarsCov2PCRTest" "testResult") "negative")
             (= (var "credentialData" "covid19Vaccination" "hasVaccination") "negative"))
         "valid"
         "invalid"))

    ["if", ["or", ["===", ["var", "credentialData.rapidSarsCov2PCRTest.testResult"  ], "negative"],
                  ["===", ["var", "credentialData.covid19Vaccination.hasVaccination"],  true     ] ],
           "valid",
           "invalid"]

?

    {... 
     parsingMatrix
     (if (or (=== (var "credentialData.rapidSarsCov2PCRTest.testresult")
                  "negative")
             (=== (var "credentialData.covid19Vaccination.hasVaccination")
                  true))
         "valid"
         "invalid")}

    (credentialData.rapidSarsCov2PCRTest.testResult==='negative')
      || credentialData.covid19Vaccination.hasVaccination) 
          ? 'valid' : 'invalid' 

Lispers are always pointing out how the parenthesis-and-whitespace notation is just incidental; how s-expressions are really something deeper that isn't bound to a specific syntax, and how this is a strength. The OP is a demonstration of that strength.

I had only a vague idea of what an AST was, but the highest upvoted comment was clearly saying: This is dumb, we have dedicated formats for turning text into ASTs. ( i.e. a programming language ).

In the past decade+? i have learned what an AST is and have now twice, in a professional setting, prevented an engineer from re-inventing this very concept.

If i had to choose if hackernews is a place where smug snark comments crack down on re-inventing known concepts or a happy place where every idea is a good one i will choose the former.

And once every blue moon we get to laugh and look back at snarky comments such as this: https://news.ycombinator.com/item?id=9224

Turing completeness.

>So I’d argue a lot of the criticism is valid.

I'd argue they should have paid more attention in college. This is far from a superficial difference.

You might as well call HTML a programming language. Seriously.

Citation? I don’t know many people who would call Brendan Eich anti-intellectual for instance.