I think I've tracked down the issue.  Check out method parseComposite at line
481 in XMLParser:

   private void parseComposite(Composite datatypeObject, Element
datatypeElement) throws DataTypeException {
        if (datatypeObject instanceof GenericComposite) { //elements won't
be named GenericComposite.x
            NodeList children = datatypeElement.getChildNodes();
            int compNum = 0;
            for (int i = 0; i < children.getLength(); i++) {
                if (children.item(i).getNodeType() == Node.ELEMENT_NODE) {
                    parse(datatypeObject.getComponent(compNum), (Element)
children.item(i));
                    compNum++;
                }
            }
        }



So, if you're processing a OBX.5 what you end up with here is a
datetypeObject of type GenericComposite containing only one component
element and a datatypeElement containing one child node, the SN.2.  

Ideally SN.2 would be assigned to the component referenced by
datatypeObject.getComponent(1) but since the code here is just basing things
on a simple counter that value ends up in datatypeObject.getComponent(0)
which ultimately becomes SN.1.

This definitely seems like a bug to me because the code needs for SN.1 to be
present in order for SN.2 to get populated correctly.  SN.1 is not required
and for a lot of the data I get it's never there.  What would it take to get
this bug fixed?  Is it going to be as simple as evaluating the field number
suffix on the element node name?  If I can write up a patch what would it
take to get the patch accepted?  And should I correspond with someone
offline to talk about the proposed fix in more detail?

Thanks,

Jim






jimski wrote:
> 
> Hi All-
> 
> I've got a document where OBX.5 contains the following SN data:
> 
> <OBX.5><SN.2>22</SN.2></OBX.5>
> 
> This should parse so that:
> 
> Comparator:
> Num1:22
> Separator/Suffix:
> Num2:
> 
> 
> But instead, Hapi parses it to:
> 
> Comparator:22
> Num1:
> Separator/Suffix:
> Num2:
> 
> Anyone else seen this problem?
> 
> There doesn't seem to be an issue processing the equivalent EDI format:
> 
> |^22| 
> 
> is handled just fine.
> 
> Jim
> 

-- 
View this message in context: 
http://www.nabble.com/DefaultXMLParser-issue-processing-SN-datatypes-tp15348062p15348422.html
Sent from the hl7api-devel mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Hl7api-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

Reply via email to