From: James A. <jam...@gm...> - 2017-05-26 11:01:07
|
Well.... These should be functionally equivalent, so it sounds like you've found a bug. Please feel free to add a ticket for this. Cheers, James On Fri, May 26, 2017 at 12:02 AM, Mike Mills <mi...@th...> wrote: > James, > > I work with David and have been working with him to get to the bottom of > the issue so that we can choose a suitable solution for us. > > We noticed that some validation is turned on when you use the pipeParser > but not when you use the parse() on a Message. eg: > > String msh_string = "MSH|^~\\&|MSH3|MSH4|MSH5|MSH6|20161221133021||ADT^A01| > MSH10|P|2.5"; > final ADT_A01 adt_a01 = new ADT_A01(); > adt_a01.parse(msh_string); > String objectParseMSH10 = adt_a01.getMSH().getMessageControlID(). > getValue(); > System.out.println(objectParseMSH10.length()); // length is 8, > spaces preserved > > ADT_A01 parsedA01 = (ADT_A01) new DefaultHapiContext(). > getPipeParser().parse(msh_string); > String pipeParsedMSH10 = parsedA01.getMSH().getMessageControlID(). > getValue(); > System.out.println(pipeParsedMSH10.length()); // length is 5, ie > spaces stripped > > > In this example the MSH10 has leading spaces and the parse() on a message > method does not strip the spaces. > > With the pipeParser method it parses and strips the spaces. > > We have always assumed that they were functionally equivalent ways of > parsing a string into a Hapi Message. > > As they are not which is the recommended way to parse a HL7 string into a > Hapi Message object? > > Regards, > > -Mike > > > > > On 25 May 2017 at 21:03, James Agnew <jam...@gm...> wrote: > >> Hi David, >> >> I'm not sure I could provide an answer as to why, given that this >> behaviour has existed in the library for roughly 15 years now. >> >> I would be nervous about changing it given how longstanding it has >> existed, but I can tell you that you can disable it by setting validation >> to NoValidation (it's the validation engine that causes this trimming). >> >> Cheers, >> James >> >> On Wed, May 24, 2017 at 11:37 PM, David Bunzli < >> Dav...@he...> wrote: >> >>> Hi, >>> >>> >>> >>> I’m experiencing a situation where an NTE-3 field handled by HAPI is >>> trimming leading spaces, eg ‘ an FT string’ -> ‘an FT string’. My >>> investigation lead me to the HAPI FAQ link >>> http://hl7api.sourceforge.net/hapi-faq.html#leading_space which >>> describes this behaviour for FT, ST and TX fields. >>> >>> >>> >>> My questions are: >>> >>> · why does HAPI trim leading spaces given that the HL7 v2.4 >>> spec ‘Chapter 2.9.48 TX – text data’ says ‘Leading spaces should be >>> included’? >>> >>> · I can’t find any reference in the rest of the HL7 v2.4 spec >>> which mentions the trimming of leading spaces. Have I missed this, or why >>> has HAPI chosen to trim? >>> >>> >>> >>> Regards, >>> >>> David Bunzli >>> >>> ************************************************************ >>> ******************** >>> >>> This email, including any attachments sent with it, is confidential and >>> for the sole use of the intended recipient(s). This confidentiality is not >>> waived or lost, if you receive it and you are not the intended >>> recipient(s), or if it is transmitted/received in error. >>> >>> Any unauthorised use, alteration, disclosure, distribution or review of >>> this email is strictly prohibited. The information contained in this email, >>> including any attachment sent with it, may be subject to a statutory duty >>> of confidentiality if it relates to health service matters. >>> >>> If you are not the intended recipient(s), or if you have received this >>> email in error, you are asked to immediately notify the sender by telephone >>> collect on Australia +61 1800 198 175 <+61%201800%20198%20175> or by >>> return email. You should also delete this email, and any copies, from your >>> computer system network and destroy any hard copies produced. >>> >>> If not an intended recipient of this email, you must not copy, >>> distribute or take any action(s) that relies on it; any form of disclosure, >>> modification, distribution and/or publication of this email is also >>> prohibited. >>> >>> Although Queensland Health takes all reasonable steps to ensure this >>> email does not contain malicious software, Queensland Health does not >>> accept responsibility for the consequences if any person's computer >>> inadvertently suffers any disruption to services, loss of information, harm >>> or is infected with a virus, other malicious computer programme or code >>> that may occur as a consequence of receiving this email. >>> >>> Unless stated otherwise, this email represents only the views of the >>> sender and not the views of the Queensland Government. >>> >>> ************************************************************ >>> ********************** >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Hl7api-devel mailing list >>> Hl7...@li... >>> https://lists.sourceforge.net/lists/listinfo/hl7api-devel >>> >>> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Hl7api-devel mailing list >> Hl7...@li... >> https://lists.sourceforge.net/lists/listinfo/hl7api-devel >> >> > |