Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binary elements are not supported #158

Open
kputnam opened this issue Jan 1, 2019 · 1 comment
Open

Binary elements are not supported #158

kputnam opened this issue Jan 1, 2019 · 1 comment

Comments

@kputnam
Copy link
Owner

kputnam commented Jan 1, 2019

The X12 standard defines element types including AN (string), ID (enum string), DT (date), TM (time), etc, and also define B (binary). Binary elements do not have a fixed length, but their length is provided in a previous element.

Because a binary element could contain an arbitrary string, it would be incorrect to read a variable number of characters until reaching an element separator (eg, *), because the element separator may occur as part of the value. Being able to read binary elements would require changes to the tokenizer -- particularly, some way to indicate which element defines the length of the binary element.

Since I haven't encountered these in practice, and I don't have documentation or examples, support for binary elements is not included in stupidedi. This issue is open to document this limitation, and to collect feedback from users on whether this should be supported.

@kputnam
Copy link
Owner Author

kputnam commented Sep 9, 2019

I stumbled across some documentation for BIN and BDS segments. It doesn't look like the typical segment detail page from implementation guides, so I probably skipped over it a long time ago.

See Section 3.11 of http://members.x12.org/technical-assessment/x12-6-dm-042316.pdf. It doesn't fully specify the element definitions (element ID, name, min/max length, etc) for BIN01 and BDS02 (number of octets), BIN02 and BDS03 (binary data), and BDS01 (filter ID). Presumably filter id specifies how to encode/decode data (eg, base64 or uuencode)?

It would be a little awkward, but the tokenizer would need to be changed to handle BDS and BIN segment IDs as a special case ("ISA" and "IEA" are already handled as special cases).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant