Hi Bryan, On Wed, Sep 12, 2007 at 11:42:41AM -0400, Bryan Tripp wrote: > > Thanks for the explanations. I think I understand where you're coming > from but I have a few more questions ... > > > 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). > > I see what you mean technically, but I don't understand the intended > usage. Suppose you had a flag that told you something in a field was > null (without specifying which part). What would you do with this? Do > you have a routine that does nothing but handle nulls, and you only > want it to traverse only relevant parts of the message? So do you need > this flag at the segment level too?
I think there's a slight confusion regarding HL7 Null's: only a field as a whole may be Null, not individual components. So, |""| says the field is Null, but |^""| says the second component has a value of "" (two quotes, not the empty string), i.e. in the latter case the "" is not a Null. So the "" is not a flag that something in a field is null, but a flag that the field itself, as a whole, is null. >From a HAPI perspective, in terms of Segment and Type, this means that there should be really a flag in Segment, something like 'isFieldNull(int field)' and 'setFieldNull(boolean flag)'; and in that case the generated subclasses should contain an isXXXNull() and a setXXXNull(boolean) method for each field. This seemed like a lot of extra methods, though, which is why I was thinking of putting the null-flag on the Type, even though that's a bit hacky because it would only be valid/honored on instances that are directly part of a segment (i.e. a field) instead of part of another type (i.e. a component or subcomponent). I.e. the flag would only be set/honored by the segment parsing/assembly code when dealing with immediate elements. Am I making sense? > > 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. > > Good point, but can't this be fixed as easily without the flag? But wouldn't the fix look something like the "fix" for field validation below? I.e. with the same problems? > > 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. > > OK, but a PrimitiveTypeRule isn't supposed to be aware of rules that > span multiple components. The only support for this kind of thing > currently would be in ConformanceProfileRule. It would make sense to > add new functionality here with a CompositeTypeRule interface. > However, I don't see how the null flag would help with this. Can you > clarify? By removing the "" during the parsing (i.e. not setting a field or a fields first component at all, i.e. apart from setting the Null flag the fields and their components are the same as if the field had been empty (||)) you can remove any special Null handling from these rules. So they would catch these invalid cases because they would only see a "" value if it wasn't a Null (as in the 2004^"" example above). 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
