RE: [HAPI-devel] ADT^A13 bad parse

[Tripp, B. <Bry...@uh...>]

Hi Archie,=20

Assuming we're in try-to-parse-everything mode, if a non-Z segment =
appears
that is not expected anywhere in the message, HAPI will assume it's a =
legal
local extension and put it at the end of the current group.  This =
approach
can yield unexpected results, but only if there is an error in the =
message.


If I understand correctly, your suggestion was to look at later versions =
of
the same message structure and switch versions if it looks like one of =
them
matches better.  I'm not enthusiastic about this, because early adopters
(even long after the fact ;) sometimes incorporate segments from later
versions into their messages, and because I think that quietly =
correcting an
error can lead to deeper confusion than either failing, or assuming =
there is
no error and returning the literal result of the call. =20

Another option would be to decorate a parser with something that guesses
message structure and version.  I.e. something you would use like this: =
new
VersionGuessingParserDecorator(new PipeParser()).  How does that sound =
to
you? =20

Bryan=20


> -----Original Message-----
> From: hl7...@li...
> [mailto:hl7...@li...]On Behalf Of Archie
> Cobbs
> Sent: December 15, 2004 3:28 PM
> To: Tripp, Bryan
> Cc: hl7...@li...
> Subject: Re: [HAPI-devel] ADT^A13 bad parse
>=20
>=20
> Tripp, Bryan wrote:
> > That's how HAPI was first implemented actually, and I agree=20
> it's the=20
> > safest.  It was changed because there were several complaints from=20
> > people who use non-standard messages, and because the HL7=20
> spec says that=20
> > unexpected segments are to be ignored (presumably so that compliant=20
> > processors don't choke on messages with local additions). =20
> How about=20
> > making this a configurable option in HAPI 0.5, i.e. the=20
> options would be:=20
> > =20
> > 1) Fail if there are any unexpected segments
> > 2) Fail if there are any unexpected non-Z segments=20
> > 3) Fail if any required segments are missing=20
> > 4) Try to parse everything =20
>=20
> That would be nice... my question though is whether the heuristic
> for option #4 can be improved to handle an unknown non-Z segment
> in the middle of a message. What it does now is not quite right.
>=20
> Thanks,
> -Archie
>=20
> ______________________________________________________________
> ____________
> Archie Cobbs      *        CTO, Awarix        *     =20
> http://www.awarix.com
>=20
>=20
> *
> Confidentiality Notice: This e-mail message, including any=20
> attachments, is for the sole use of the intended recipient(s)=20
> and may contain confidential and privileged information. Any=20
> unauthorized review, use, disclosure or distribution is=20
> prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and=20
> destroy all copies of the original message.
> *
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>=20