Dale Marthaller <[EMAIL PROTECTED]> wrote:
>Does anyone have a work around for a situation where a trading partner
has
>imbedded data containing the same character as the element separator.
Others have given very practical advice for dealing with this X12
problem. If your trading partner remains unconvinced by practical
considerations, let me offer standards and theoretical considerations.
On a standards basis, you can always quote to them X12.6, section 3.4:
"Delimiters are specified in the interchange header and shall not be
used in a data element value elsewhere in the interchange with the
exception of their possible appearance in the binary data element."
That's from version 4040, but I'm sure it has been there for *quite*
some time.
On a theoretical basis, If we look at the theory of how computers
process languages (automata theory), we can prove that there is no
workaround. It's not a limitation of anyone's translator software, it's
a logic problem. The only way to deal with the situation would be for
your software vendor to write their translator so that it "guesses" as
to whether an asterisk was data or a delimiter, and then backtrack and
take the other choice if parsing failed. This kind of
"non-deterministic" programming is rarely implemented in business
software for obvious reasons. This is the source of the restriction in
X12.6 - it's a lot easier and more efficient to write "deterministic"
programs that don't have to guess about what they're looking at.
As others have noted, the ISO 9735 syntax used in UN/EDIFACT has no
such restrictions since it features a release character.
--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
