Maybe I missed it as part of the multiple messages about 997's, but it is worth repeating. The 997 is used for more than just a response that you received data. It includes checking syntax, including looking for missing mandatory segments and elements, looking for improper structure, completeness of the message using control numbers and segment counts. And with the recent changes in X12 it will even allow someone to check against an Implementation Guide.
With all of the work that I have done with XML I have yet to see anyone implement a similar type of control structure. Whenever I have asked the response you always get is that is only a problem in EDI because of its weaknessess and will not be a problem with XML. Yet I have seen incomplete XML data exchanged and the only way to resolve it is a phone call.
Anyone else have similar experiences?
Dwight
>From: Rachel Foerster <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: CONTRL message woes
>Date: Thu, 12 Apr 2001 17:08:00 -0500
>
>Erlend,
>
>Perhaps. But the question is....is your XML parser just an XML parser or a
>validating parser. If a validating parser, then it will validate the XML doc
>against the specified DTD. If the doc does not comply with the specified
>DTD, then what? The validating parser will output (hopefully) an error
>message....where, to whom? How will the originator of the XML doc know it
>didn't pass muster. And then, what about validating against a W3C Schema
>(if, when it's approved). What are the rules of the road here? Are there
>any? I don't see them yet. In other words, where's the clear, unambiguous
>and reliable audit trail? Does anyone care?
>
>These are, in my mind, still unanswered questions.
>
>Rachel
>
>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/
>
>=======================================================================
>To contact the list owner: mailto:[EMAIL PROTECTED]
>Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
Get your FREE download of MSN Explorer at
http://explorer.msn.com
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
