You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: