Hi Bryan,
thanks for your reply.
On Mon, Sep 10, 2007 at 09:26:19AM -0400, Bryan Tripp wrote:
>
> I'm not sure I understand the motivation for handling them specially.
> Nulls (as opposed to empty fields) are to indicate that corresponding
> data should be deleted from the receiving application. This is
> supported -- if a field contains "\"\"" then the application should
> delete data -- but it isn't HAPI's business to enforce this, so I
> don't understand why special treatment is needed.
>
> Can you explain further? E.g. what makes it difficult to check that
> something is null, and what validation errors are you getting?
There are three problems, really:
1. Checking for Null currently is hard, because you actually have
to check all parts in a composite type. E.g. for a field of type
XPN you have to check that XPN.1.1 is "", XPN.1.2 is empty,
XPN.1.3 is empty, etc, then XPN.2 is empty, XPN.3 is empty, etc.
Yes, if XPN.1.1 is "" then chances are small it wasn't an
Null, but, say, a surname of "" is legal if at least one other
component in the field is valued (i.e. a PID-5 field of ""^John is
legal, though unusual).
2. Profile validation fails when the first item in the type is
constrained to have a length of 1. E.g. Nulls in boolean fields
PID-8, PID-24, PID-30, PD1-12, and PV2-22 all cause validators to
complain.
3. I would argue that the current Null handling in the
RegexPrimitiveRule is wrong, because does not take the whole field
into account. For example a field of type DR with the value
2004^""^ (or e.g. a PID-5 of ^^^^^^^^^2004&"") passes validation
despite being invalid.
Having the parsers recognize Null and setting a flag instead of
assigning "" as the first component's value fixes all these problems.
Cheers,
Ronald
> On 8/31/07, Life is hard, and then you die <[EMAIL PROTECTED]> wrote:
> >
> > We're trying to handle hl7 update messages, and these may contain hl7
> > null's (""). HAPI does not currently seem to handle them specially,
> > which leads to various problems, such as validation failures and
> > making it somewhat torturous to detect these nulls.
> >
> > I've been trying to figure out what the best approach for handling
> > nulls would be, and came up with the following: add two methods to
> > Type, 'boolean isNull()' and 'void setNull(boolean)'. The parsers
> > would set the null-flag appropriately, and the encoders and verifier
> > would simiarly check the flag; setting the flag on instances that are
> > part of another composite type (as opposed to part of the segment
> > directly) would have no effect.
> >
> > I've done a quick implmentation of this and it works reasonably well.
> > But I wanted to gather feedback on the approach before submitting a
> > patch. Is there a better alternative? What have others done? Have I
> > missed something?
> >
> > TIA.
> >
> >
> > Cheers,
> >
> > Ronald
> >
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Hl7api-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
