#124 Hapi-sourcegen problem

None
closed-fixed
nobody
None
5
2013-01-21
2011-06-28
No

When we have defined our HL7 message profiles we used table names of type XXXDDDD where XXX is IHE and DDDD a number. This allows us to specify the name of tables that are not HL7. Although the profiles are compliant with the HL7 Message profiles XSD, the source-gen tool of hapi is complaining that we do not use a int there.
Please what is the rational to restrict that field to a number and forbid strings ?

see line 41 of the file :
http://hl7api.cvs.sourceforge.net/viewvc/hl7api/hapi-mvn/hapi-sourcegen/src/main/java/ca/uhn/hl7v2/sourcegen/SegmentElement.java?view=markup
41 public int table;

Discussion

  • James Agnew

    James Agnew - 2011-09-11

    Hi Eric,

    The problem appears to be a conflict between HL7 chapter 2, which defines table names as numeric, and the conformance profile spec, which defines them as strings. The problem with reading in strings is that the HAPI primitive types use int (see https://hl7api.svn.sourceforge.net/svnroot/hl7api/trunk/hapi-mvn/hapi-base/src/main/java/ca/uhn/hl7v2/model/primitive/ID.java for an example), so allowing strings would be a change to a pretty fundamental part of the API.

    Do you think it would suffice to just ignore non-numeric values in the XSD and parse them as "0"?

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2011-09-12

    Hi James.

    I understand that this is a big change and I am ok to consider alternative solution.
    Ignoring the non-numeric part values in the XSD would allow to solve the problem of the parsing of the message profile by HAPI.
    However this is not sufficient for solving my problem. If I define a table like IHE0234 where I have the possible values for a specific field.

    Then how will the validation check the content of the values in the field ? It will search for values in HL70234 as the HL7 prefix string is added by HAPI to identify the table to use for the validation of the content.

    Do you have any suggestions ?

    Could we define ranges for tables domain ?
    IHE0234 converted into 10234 and then converted back to IHE0234 because tableId > 9999
    HL70234 converted into 234 and then converted back to HL70234 because tableId < 10000

    This is not really clean but could work without changing the primitive types.

    Thanks for your feedback

     
  • James Agnew

    James Agnew - 2011-10-24

    Hi Eric,

    I've given this a bunch of thought, and I have a new idea. I'm thinking I could create a subclass of ID and IS that accepts a table namespace, and have the sourcegen use that when it's needed. That way you could make use of the namespace data (basically either "HL7" or "IHE" without having any effect on anyone who is using the standard library classes and may have serialized them.

    By any chance would you be able to provide a conformance profile XML that illustrates the issue so that I could form a unit test?

     
  • James Agnew

    James Agnew - 2012-07-12

    Note that a fix for this has been partially checked in. Currently the source generator is able to parse table namespaces, and can create segment structures which leverage specialized "IDWithNamespace" types. This wont be truly useful (or intuitive) until the sourcegen maven plugin understands the "ALL" datatype mode though, so I am going to leave documentation and announcement of this feature to after 2.0.

     
  • James Agnew

    James Agnew - 2013-01-21

    Documentation is finally complete for this.

    Closing.

     
  • James Agnew

    James Agnew - 2013-01-21
    • status: open --> closed-fixed
    • milestone: -->
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks