Complete X12 Schema and DOM

[ahuggins-nhs]

Add remaining classes/objects necessary to describe ASC X12 Make schema feature-complete with ASC X12 Make DOM match ASC X12

[sambacha]

don't know if you are looking for this still, but github.com/freight-trust/libedi

[ahuggins-nhs]

@sambacha It looks interesting. I wasn't exactly looking for what's happening in libedi exactly. I view x12 as a document format, like xml, pdf, or rdf, and I'm trying to carry on this library as a low-level parser that supports and describes the different features of the document format as a syntax tree. The libedi work looks like it's describing things at a pretty high (almost data) level.

Do you have any thought as to how the node-x12 effort and the libedi effort can interact? I'm also curious about the validate method I see, as I just released a validation engine for which validation maps can be written. I wonder if there can be any unification of efforts on that, as well.

[fpw23]

@sambacha i think what you are doing makes sense because I ran into the same issue when using this lib and I had to figure out a way to validate the segments I cared about. This lib is awesome and allowed me to ditch the EDIDev framework we had to buy long ago but as @ahuggins-nhs mentioned it is lower level than data so you have to do some extra coding to make it meet your needs. Not necessarily a bad thing, the lower the level the more flexibility but with great power comes great responsibility ;)

This is where I believe making a micro service UI that allows someone to quickly utilize this library would be awesome! I have recently used google blockly on a project and had great results. My vision I think is somewhere in between both your efforts. It looks like to me in github.com/freight-trust/libedi you are defining every message type in order to get validation, this is what I had to do as well for my medical segments. Statically defining them in code works but what if that were not necessary? Since the definition is just JSON anyways its pretty easy to store in a flat file or db. Once you have that done then it is much easier to support validation/parsing/generating for any industry. If you couple dynamically created segment validation with dynamic scripts for parsing and generating all in a easy to use web app it makes adopting EDI into anyone's project extremely quick. I have a POC I did to flesh out some of these ideas and it is working great in test.

The crossroads I am at is whether or not this is needed? I only have limited EDI exposure in my medical app so I don't know the scope of EDI use in other industries. @sambacha do you think this would be something useful in transportation?

[sambacha]

Thanks @ahuggins-nhs and @fpw23 for the feedback, one thing: we moved libedi to (libinterchange](https://github.com/freight-trust/libinterchange)

The new library is much more extensive, with X12 the priority. You can see that X12 is the most detailed by these groupings:

X12 Modules - These are the transaction 'meta' set with names. they are not versioned and do not contain any schemas/etc, but rather the 'planned' placed to put docs/ESC guides/etc.

packages/X12005040 a typescript implementation of an entire version of transaction sets

https://github.com/freight-trust/Schemas/blob/master/EDISchemaV4.xsd our reference schema we use

Additionally, as this is alot of data for anyone to handle, we thought about creating a modernized version of .SEF (really just an .INI file) called XSEF modeled after npm. tl;dr = xsef is just a structured format for sharing schemas, connection info, and validation rules (just like how a JAR file is a special kind of ZIP in the sense that it is very structured in terms of folder structure, etc).

https://github.com/xsefpm/xsef & read the specification and initial implementation

And also really like the JSEDI Notation @ahuggins-nhs - here is our version in fact (its more based off of XPath than your notation grammar: ediq

edit: linked to a gist that provides an install and directions (JAR / NPM package) as our repo is private for source for now, apologies.

Our EDI Parser SaaS platform can also be found here: http://testing.freighttrust.com/ here is the swagger spec: https://github.com/freight-trust/open-edi

After doing all this, I can say that facilitation of an agreed upon schemas, and more importantly, validation rules, reduces onboarding pains considerably.

I also know that @ahuggins-nhs is working on a library for AS2, we are in fact releasing our AS2 implementation sometime in the first week of November. It is from the ground up new and performant. Just to note, Drummond certification doesn't mean anything really anymore, I know of AS2 drummond servers that can not be used by federal agencies for example, so don't hold it in high regard.

Will be getting corporate license for X12, so if you guys ever need an artifact, etc, just let me know,

Thanks,

Sam

[ahuggins-nhs]

@sambacha Cool 😮. This will take a while for me to look at with how busy I've been on other projects.

AS2 has taken a bit of a back seat as my manager is re-evaluating priorities; is your implementation a library that can be used in JavaScript/TypeScript? I ask since there are quite a few implementations in Java, but none native to JS (which would lend itself to use in Azure/AWS/etc.).

[ahuggins-nhs]

Closing, as work will eventually continue in the JS-EDI project.