4 ms·

> beneficiaries of your standard are the actual farmers, labs, and retailers Yes, this has been our entire focus. > hacking some glue scripts together We're

• andjd 5y ago
  > two simple JSON data models and some specifications in YAML More power to you if it is this simple. Just bear in mind that while the structure is probably a good fit for the data model in your database, it's probably not such a good fit for anyone else, so other vendors probably won't see it as quite so 'simple'. Another benefit of a standard like this is that when it comes to interoperability between two companies is that it splits up the role of who has to do the hard work to build the integration. Every vendor want's to point the finger at the other guy and say 'it's his problem'. If there's a standard, it's harder to pass off these dev costs onto others. Especially since this is your standard (and, presumably, you don't have to do more work to support it) your call for your peers to support the standard can come across as sneaky way of passing off the work of integration to them.
  • openthc 5y ago
    > structure is probably a good fit for the data model in your database Um, actually we made some not optimial choices with our initial app-data schema and working with other vendors got us to this one. And also, yes, because we've used it for integration in a few places before, there is less work for us to currently do. We have also offered to help other providers wherein we would be spending our own cash-time for a mutual benefit.