Hacker News Reader

Comment by asah | Hacker News Reader

I'm not sure how to express how much I loathe everything about this "solution."

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

View on HN

Ok, I take your point, but let's say we need to share these credential objects between different systems that do not have prior knowledge of how to evaluate the credential data. Also, let's say we constrain the logic to only allow for evaluation of any given part of the credential data against a binary "pass | fail" matrix.

What is a better way to share this important part of the schema (the matrix) without resorting to letting the "business logic" perform the evaluation? Optimally, any matrix should be able to run against the same business logic for evaluation.

Also, though I understand why you say that, we won't have "100 other yahoos doing this nonsense," and each schema would go through a pretty thorough review process.

If your business logic doesn't meet the needs of your business without the schema, the schema is a part of your business logic, that should be subjected to a suite of automated tests.

If your concern is the sharability, consider making a library or service that provides the business logic.

We'd like to be able to include evaluation matrices within credentials as an extension to the Verifiable Credentials standard (see https://www.w3.org/TR/vc-data-model/). Optimally, different libraries and different services will be able to evaluate a credential using the credential's included matrix (i.e. the evaluation matrix should not be reliant on any business logic from any particular party). I can't get too deep into the use-case but having these parts bundled together is important for what we're working on.

> but let's say we need to share these credential objects between different systems that do not have prior knowledge of how to evaluate the credential data

Well, they _must_ have prior knowledge about it, because they must have to understand the concept of JsonLogic beforehand. So instead, you can just make these systems understand a proper programming language that can produce outputs. Something like https://github.com/dhall-lang/dhall-lang would probably be a much better option for this usecase.

With the standard that we're working with (the W3C's "Verifiable Credentials" standard [0]) having something that's in JSON or at least "JSON-compatible" is quite important.

[0]: https://www.w3.org/TR/vc-data-model/

No problem, just serialize the dhall into a json string.

What about an "isValid" field returned by your API?

Your problem is that you need the same logic in two places, and you can solve it by centralizing this logic in one place.

Sometimes you need to embed an expression interpreter in your application, for example to allow users to define them at runtime. In cases like that one, having a library with a well defined specification could save a lot of time.

It's much more likely that the library would do more harm than good.

Libraries tend to cover broader spectrum of use cases than you'd need. Usually that's okay (eg: URL parsing, string manipulation, HTTP client, etc) but in cases like this the logic schema should be as absolutely minimal as possible.

If you're building an interpreter and need an interchangeable format then you can always generate that out of your own bespoke and very constrained format.

Reply on news.ycombinator.com