3 ms·

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 pr

by asah 5y ago

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

sebmellen 5y ago
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.
- omegaworks 5y ago
  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.
  - sebmellen 5y ago
    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/ 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.
    - deleted 5y ago
      [deleted]
- valenterry 5y ago
  > 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 https://github.com/dhall-lang/dhall-lang would probably be a much better option for this usecase.
  - sebmellen 5y ago
    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/ https://www.w3.org/TR/vc-data-model/
    - valenterry 5y ago
      No problem, just serialize the dhall into a json string.
- nimchimpsky 5y ago
  you haven't taken the point. JsonLogic is just an attempt to define a syntax, where no one wants one. No prior knowledge ? This is just false, its downloading the jsonlogic, and has been programmed to cope with jsonlogic. jsonlogic is an abomination.
- Seb-C 5y ago
  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.
mvaliente2001 5y ago
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.
- 0xFACEFEED 5y ago
  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.

by asah 5y ago

sebmellen 5y ago

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.

omegaworks 5y ago
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.
- sebmellen 5y ago
  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/ 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.
  - deleted 5y ago
    [deleted]
valenterry 5y ago
> 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 https://github.com/dhall-lang/dhall-lang would probably be a much better option for this usecase.
- sebmellen 5y ago
  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/ https://www.w3.org/TR/vc-data-model/
  - valenterry 5y ago
    No problem, just serialize the dhall into a json string.
nimchimpsky 5y ago
you haven't taken the point. JsonLogic is just an attempt to define a syntax, where no one wants one. No prior knowledge ? This is just false, its downloading the jsonlogic, and has been programmed to cope with jsonlogic. jsonlogic is an abomination.
Seb-C 5y ago
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.

mvaliente2001 5y ago

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.

0xFACEFEED 5y ago
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.