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 <m...@themills.id.au> 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 <jamesag...@gmail.com> 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 <
>> david.bun...@health.qld.gov.au> 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
>>> Hl7api-devel@lists.sourceforge.net
>>> 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
>> Hl7api-devel@lists.sourceforge.net
>> 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
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
