Rachel,
couldn't the situation become different with XML? The EDI translator
is usually an add-on to a piece of software, and there are some
translators that do not really support the construction of 'valid
transactions/documents' (meaning that it is as easy to create invalid
documents as it is to create valid documents, and there are no easy
ways to validate a document against a standard). Now (validating?) XML
parsers seem to be(come) a standard part of many pieces of software,
so we could start seeing the first pieces of software that do create
'valid transactions/documents'. At least the necessity to have an
automated process to deal with the reporting of processing exceptions
will become a lot less (assuming that the reason for the automated
process is that there are so many exceptions). But as you say, this is
theory.
rgds,
Erlend.
Rachel Foerster wrote:
>
> Erlend,
>
> A very simple answer. However, if this worked in the real world one would
> have no need of a 997, 824, or any other kind of response transaction in
> order to report processing results, exceptions, etc. In a perfect world, the
> originaltor would always create valid transactions/documents, but we don't
> live in a perfect world.
>
> Nice in theory, but doesn't work in practice.
>
> RAchel
>
> I guess the way to deal with this is to ensure that the document
> complies with a DTD before it is sent?
>
> Erlend.
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
