Forum - XML Standard

 View Only

  • 1.  Edit Engine and XML

    Posted 05-06-2021 03:08 PM
      |   view attached
    • December 17, 2019 at 10:41 am
      Stefan Winden

      Hi,

      Does anybody have insight into whether future versions of the Edit Engine will support processing NAACCR XML files directly, meaning the flat file (buffer) layout will eventually go away? I was thinking something along the lines of the engine parsing the XML file and then running edits on each patient/tumor in the file, so there'd be no need for any application logic to convert the XML file to a flat buffer. Thanks!

      December 17, 2019 at 11:30 am
      Kathleen Beaumont

      Hi Stefan,

      I discussed this topic in the XMLExchange Plus help file. (See topic Understanding XML Dictionaries -> Dictionaries Are NOT Needed to Run EDITS -> The Edit Engine Still Expects a Flat Buffer.)

      Apart from the horror of all that would have to be redesigned in the Engine to accommodate this request, the multi-dimensional nature of XML would impact the logic of individual edits. For example, since Tumor data items exist in a many-to-one relationship to a Patient, the logic would have to be rewritten to loop through instances [1] to [n] of every Tumor item. This would ruin one of the major features of the EDITS software: its approachability for people who do not have programming backgrounds. Also, there are many thousands of legacy edits out in the field, still in use after decades, that somebody would have to rewrite.

      (I'll attempt to attach a screen shot from the help file to this message; not sure if it will work.)

      The Engine should not be concerned with the data source. You don't expect the Engine to know how to read and retrieve data directly from your database. The Engine's job is to give you the tools (APIs) you need to know where it can expect to find each data item in the record buffer; it's up to the calling software to prepare the data for processing accordingly.

      Of course, I'm a member of the old guard, so there is no telling what the future may hold!

      Kathleen

      December 18, 2019 at 8:05 am
      Stefan 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.

      Stefan