[HAPI-devel] RE: new feature (making the PipeParser able to recover from errors)

[alexei g. <ale...@ho...>]

[Bryan] I want to move all validation to a separate process that is much
more configurable (i.e. not perform any validation when values are set,
which would fix this problem and others).  However, this is a =
substantial
change.  We have lots of new features that should be consolidated into a
stable release (0.4) before starting something new, so let's just get =
0.4
done and then we can turn our attention here. =20

=20

[Alexei] Yes, I remember that we talked about this issue some time ago =
and
you said you=92ll be working on it in the future. I think that the =
framework
you proposed to build for validation will take a long time to implement, =
on
the other side, the change I=92m proposing is very easy to incorporate =
into
hapi without incurring into the risk of introducing errors. Keep in mind
that the validation code will still be respected by the recovery handler
(when the setValue method is called from within it) meaning that the =
user
won=92t be able to assign arbitrary values to the parsed component. And =
I very
much think that introducing this sort of feature early, will help to
increase the user base of hapi. (and I=92d like to emphasize that this =
is a
core feature of all parsers, error recovery). The point I=92m trying to =
make
is that, maybe we should include it as soon as we can, maybe right after =
the
0.4 release, in some sort of 0.4.1 version .. bla bla bla ;)

=20

alex6

=20

=20

=20

=20

=20

 -----Original Message-----
From: alexei guevara [mailto:ale...@ho...]
Sent: May 8, 2003 11:37 AM
To: hl7...@li...
Subject: [HAPI-devel] new feature (making the PipeParser able to recover
from errors)

We are using HAPI to parse ADT and ORDER messages at UHN, and because of
some "lack of std. compliance" by our HIS, we are getting invalid =
messages
(not at the message structure level, but at the primitive level). For =
ex.:
some components that are meant to be numeric are alphanumeric.

=20

My proposal is simple and easy to implement. We'll be adding an event
handler to the parser to be invoked whenever such parsing error occurs, =
and
the code in the event will try to recover from that error, by marking =
the
parsed component as recovered and assigning a valid value to it.

=20

Right now this functionality will have to be added at the PipeParser =
level,
I propose to perform some refactoring in the future, such a way we can =
make
this sort of functionality common to all parser impls.

=20

Some pseudo-code implementing the described feature.

=20

class PipeParser {

=20

boolean parse(

Type destination,=20

String data,=20

EncodingCharacters encodingChars,=20

boolean subComponents) {

=20

...

           else if (destination instanceof Primitive) {

                Primitive prim =3D (Primitive) destination;

                try {

prim.setValue( Escape.unescape(data, encodingChars) );

}

catch (DataTypeException e) {

     //try to recover

     boolean recovered =3D invokeRecoveryHandler( data, destination, e =
);

     if (recovered=3D=3Dtrue) {

           //we must change the primitive intf. a bit

           prim.setRecovered( true );

}

else {

     throw e;

}

}

=20

                isLeaf =3D true;

            }

=20

...

=20

}

=20

}

HYPERLINK "http://www.mailfiler.com"MailFiler [AG-JU4UEF4]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

=20

=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003



This e-mail may contain confidential and/or privileged information

for the sole use of the intended recipient. Any review or distribution

by anyone other than the person for whom it was originally intended is
strictly

prohibited. If you have received this e-mail in error, please contact =
the
sender and

delete all copies. Opinions, conclusions or other information contained =
in

this e-mail may not be that of the organization.



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
=20