ReqIf XML export

[bavovanachte]

In order to be able to import requirements made using this tool into other requirement management tools, an export feature with standardized format would be very useful. ReqIf seems like an excellent candidate.

Original issue: #31

[bavovanachte]

As for the ReqIf output, I've taken a closer look at pyreqif. My findings:

• I have the impression that it doesn't implement all aspects of the ReqIF. It provides some convenience functions, but is not exhaustive

• Some of the "convenience functions" don't seem very intuitive to use. Example:

  pyreqif.create.addReq("_6", reqirementTypeId, "<div>Hallo</div>", collumn1typeId, mydoc)
  pyreqif.create.addReq("_6", reqirementTypeId, "<div>Hallo2</div>", collumn2typeId, mydoc)
  

  This piece of code doesn't add 2 requirements with the same name and a different attribute. It generates 1 requirement "_6" and assigns 2 attributes to it.

  The resulting xml:

    <SPEC-OBJECTS>
        <SPEC-OBJECT IDENTIFIER="_6" LAST-CHANGE="2020-04-17T13:45:20.184782">
          <TYPE>
            <SPEC-OBJECT-TYPE-REF>_3</SPEC-OBJECT-TYPE-REF>
          </TYPE>
          <VALUES>
            <ATTRIBUTE-VALUE-XHTML>
              <DEFINITION>
                <ATTRIBUTE-DEFINITION-XHTML-REF>_4</ATTRIBUTE-DEFINITION-XHTML-REF>
              </DEFINITION>
              <THE-VALUE>
                <xhtml:div>Hallo</xhtml:div>
              </THE-VALUE>
            </ATTRIBUTE-VALUE-XHTML>
            <ATTRIBUTE-VALUE-XHTML>
              <DEFINITION>
                <ATTRIBUTE-DEFINITION-XHTML-REF>_5</ATTRIBUTE-DEFINITION-XHTML-REF>
              </DEFINITION>
              <THE-VALUE>
                <xhtml:div>Hallo2</xhtml:div>
              </THE-VALUE>
            </ATTRIBUTE-VALUE-XHTML>
          </VALUES>
        </SPEC-OBJECT>
  

• Pyreqif seems to want to abstract away as much as possible from the specifics of the spec itself, meaning that fine-grained control isn't possible.
  I'm all for some abstraction functions to make the code a bit more easy to read, but it makes sense to me to still be able to access the low-level
  elements if needed

Conclusion: In my opinion, pyreqif is not at the maturity we would need.
If we would start to use it, I have the feeling we would need to do a bit of work on a library that needs improvements on the architectural level as well.

[bavovanachte]

As an alternative option, I've started playing around with pyxb instead. This is a library that generates python classes/bindings automatically based on XSD files.

I've generated the reqif files (I think they're still version 1.0) and started playing around with them here: https://github.com/bavovanachte/reqif_pyxb_tryout

I haven't moved very far yet, but up until now, the advantages I see are:

• The generated python classes provide an architecturally more sound foundation. We can build convenience functions on top that give access to the full flexibility that the XML schema offers.
• This can be done without worrying about xml generation. The classes generated by pyxb also allow generation of the xml again.
• Validation of the xml schema as it's being generated, giving more confidence that the XML output is sound and could be accepted by other tools.

My plan is to try to produce the same xml output using pyxb as the one produced by the example script in the pyreqif repo, and present the differences here for evaluation.

[bavovanachte]

Small update: I've advanced quite a bit with the pyXB approach. I've added a first layer of convenience classes on top of the pyXB ones, and added an example that uses most of them.

I've also done a first quick-and-very-dirty integration in here and managed to produce a reqif file based on the example project: if you're interested: exported_items.reqif.zip. This doesn't contain any links between the requirements yet, but it should be reqif-compatible (I can open and inspect it with the rmf eclipse plugin)

One of the things I didn't get right yet is the inclusion of xhtml in the xml tree, which is a quite important element (we'll want to store formatted text). That could be a make-or-break aspect for this approach.

[bavovanachte]

I'm closing #166 without merging. Although promising as a concept, the PyXB project doesn't seem to have a responsive owner, or a responsive community. That wouldn't be a major issue if the (generated) code was easy to understand and modify to our needs, but it doesn't seem to be. I don't think this is the right approach. I did learn quite a bit about the reqif standard, so this might help adopt, write or contribute to a different tool.