Stefan Winden

Stefan Winden

Forum Replies Created

Viewing 1 post (of 1 total)
  • Author
  • in reply to: Edit Engine and XML #12157
    AnonymousStefan Winden

    Hi Kathleen,

    Thanks for your reply. I did see the discussion in the XML Exchange Plus help file, and it makes total sense to me not to change the edit logic to accommodate a specific file format. What I was thinking of is more along the lines of passing the whole XML file to the Edit engine, and then the engine does the parsing and looping/iterating over each patient and tumor record internally, identifying the data items and making them available with the known item names to each edit’s algorithm as it does now, and then invoke the existing edit logic for each tumor in the XML file. So basically the XML parsing and field mapping logic that is expected to be done from the calling application now (and that is described in the XML Exchange Plus help) could be moved inside the Edit engine as a convenience to the application developers. I realize that this would require a significant redesign to the Edit engine and introduce an XML parsing dependency but it would seem a lot easier and beneficial to all calling applications. Plus, the flat file layout could be retired completely. It is a bit counter-intuitive that on one hand, we are switching to the XML format but on the other we still need to maintain a flat file (or flat buffer) layout for the Edit engine. It looks like we could eliminate the need for this if we passed XML to the Edit engine directly, or another (dictionary) format that isn’t relying on positional parameters.

    I agree that the engine should not be concerned with the data source but there has to be a format specified in which it accepts the data, and whether that is a flat buffer or XML doesn’t change that paradigm in my opinion.


Viewing 1 post (of 1 total)

Copyright © 2018 NAACCR, Inc. All Rights Reserved | naaccr-swoosh-only See NAACCR Partners and Sponsors