RE: [HAPI-devel] new validation model

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

Hi Alexei, 

Great idea, I hadn't thought of using regular expressions but of course it's
a good way to do it.  I bet most of the datatype rules could be implemented
in that way.  

That said, I'd prefer to implement at least the standard rules as classes
(even if they just contain regular expressions) than put the expressions
themselves in a file, because: 

1) These rules are part of the standard, so fairly static.  I'm guessing it
will be relatively uncommon to want to edit them.  

2) Not all datatype rules would be best implemented as regular expressions
... for example dates (probably better to use a GregorianCalendar) and
validating vocabularly against tables.  

3) It would also be nice to keep the class structure fairly similar to the
MessageRules and EncodingRules (where we can't use regular expressions).  

How about this ... we use individual classes for the standard rules, and
also create a RegularExpressionRule class that could be configured with some
arguments in the property file.  Like this: 

ca.uhn.hl7v2.validation.datatype.TNFollowsNorthAmericanFormat = off
ca.uhn.hl7v2.validation.datatype.TNFollowsUKFormat = on
ca.uhn.hl7v2.validation.datatype.RegularExpressionRule = TN,/^(\d{3})
\d{3}-\d{4}$/

How does that sound?  

I realize we might end up with a lot of rule classes, which at some point
would become annoying.  Maybe we should get a rough count of the rules
fairly soon?   

Bryan 

> -----Original Message-----
> From: Guevara, Alexei [mailto:Ale...@uh...]
> Sent: October 11, 2002 12:52 PM
> To: 'hl7...@li...'
> Subject: RE: [HAPI-devel] new validation model
> 
> 
> ... Maybe this validation module is a perfect fit for regular
> expressions, and even more now that the jdk1.4 has optimized 
> support for
> it ... we could have a file with global validation rules, expressed as
> regular expressions (for data types), but the end user will be able to
> override those rules as well in some user suplied file ...
> 
> alex6
> 
> -----Original Message-----
> From: Tripp, Bryan
> To: 'hl7...@li...'
> Sent: 10/11/2002 12:44 PM
> Subject: [HAPI-devel] new validation model
> 
> Hi Everyone, 
> 
> I've been speaking with Alan Shields and Neal Acharya about a new
> validation
> model for HAPI.  This seems like a good candidate for a new 
> sub-project,
> so
> if anyone is interested in working on this please let us know.  
> 
> Currently, the only run-time message validation HAPI performs 
> is within
> the
> setValue() methods of the Primitive datatype classes.  For 
> example when
> you
> call setValue() on a DT an exception is thrown if the String 
> arg is not
> in
> the correct DT format.  This has served pretty well so far 
> but it leaves
> us
> with the following limitations: 
> 
> 1. Sometimes validation is inappropriate.  This is the 
> problem Alan ran
> into
> -- the TN class was rejecting his perfectly valid UK telephone numbers
> because they didn't conform to the North American format.  
> 2. Can't add further optional constraints (such as all timestamps must
> have
> a time zone).  
> 3. Can't turn off validation to improve performance. 
> 3. Other forms of validation (e.g. conformance profiles, 
> standard DTDs)
> are
> not covered.  
> 
> We're considering expanding run-time validation and making it
> configurable.
> In a nutshell, the idea is to implement each validation rule as a Rule
> object with a test() method that could be invoked or not, depending on
> run-time configuration.  Three types of rules seem appropriate: 
> 
> 1. DataTypeRule: Called when the values of simple datatypes are set,
> like
> the existing hard-coded datatype validations (e.g.
> TNFollowsNorthAmericanFormat).  
> 2. MessageRule: Called when complete message content is to be 
> checked on
> a
> parsed message (e.g. conformance profile). 
> 3. EncodingRule: Applied to an encoded message (e.g. 
> validation against
> a
> 2.xml Schema, a rule that prohibits empty tags, etc.).
> 
> We would attempt to ship HAPI with all the rules identified by the HL7
> standard, enabled by default, and called at logical points in message
> processing.  Users could disable the rules, call the rules
> programmatically
> at different points in their own code, and create their own rules if
> they
> wish.  Rules could be turned on and off at run-time, possibly 
> by editing
> a
> property file with one entry per class, like this (the entries below
> refer
> to implementations of DataTypeRule):
> 
> ca.uhn.hl7v2.validation.datatype.TNFollowsNorthAmericanFormat = off
> ca.uhn.hl7v2.validation.datatype.TNFollowsUKFormat = on
> 
> The beginnings of a suggested class structure are attached.  
> 
> Is anyone else interested in working on this?  Feedback is 
> most welcome.
> 
> 
> Thanks, 
> Bryan 
> 
> 
> 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.
> 
>   
> 
>  <<validation.gif>> 
> 
> 
> 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.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


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.