3 ms·
I absolutely love the insight. I have some nitpick of course :) > just build off the open source code and data structures instead of having to re-implement i
by dmitriid 4y ago
I absolutely love the insight.
I have some nitpick of course :)
> just build off the open source code and data structures instead of having to re-implement it all from RFCs and other loose spec documents.
It's never "just". What you're providing are exactly lose specs. E.g. "Serialization of signed data structures (AMQP+extensions)". What are the data structures? What do they look like? Which extensions? What happens if someone doesn't support all the extensions?
RFCs and standards however bad they are exist for a reason. And even then people implement them poorly, or not at all.
> hard to make work due to the massive variety of players, hard technical challenges and complex commercial/geo-political concerns.
Unfortunately, in this list technical challenges should go last. For all the reasons you described in the first half of your message :)
- mike_hearn 4y agoThe data structures can be found in the code, but I agree it'd be better to have a spec. I tried to design it so one day such a spec could be written (lots of dependencies on pre-existing specs for example) but it never became a priority.
- seymore_12 4y agoMajority of shipping/trading documents are formalized under EDIFACT standard for example, this is the layout of Bill of Lading/Shipping Instruction, so called IFTMIN https://service.unece.org/trade/untdid/d04a/trmd/iftmin_c.htm https://service.unece.org/trade/untdid/d04a/trmd/iftmin_c.ht... One of the possible reasons for TradeLens demise is that they choose to ignore them and came up with their own data structures (Json) i.e. partners that are usually EDIFACT capable had to practically start from scratch to comply with TradeLens format. At some point TradeLens realized that and started partially accepting EDI feeds, but it was too little, too late I guess.