Excel importer

[BenGardiner]

We implemented a simple excel importer that takes the first sheet, finds well-kwown columns via header strings and creates custom grammar for all the other columns. It is MIT licensed here https://github.com/nmfta-repo/nmfta-vehicle_cybersecurity_requirements/blob/0240a08f0ff0024ba093930ff37cc1589de25b67/scripts/import-tsrm.py#L22

Is this a candidate for inclusion into strictdoc (only csv import/export was on your backlog)?

If yes, where's the best place to put it in the file-tree?

[stanislaw]

Is this a candidate for inclusion into strictdoc (only csv import/export was on your backlog)?

Definitely yes!

If yes, where's the best place to put it in the file-tree?

Good question. Basic Excel export is in export/excel. I was thinking of restructuring the top level at some point, don't have a good idea for this Excel part.

The best existing folder would probably be backend/ where you could put your code under backend/excel/import.

I am also open to considering alternatives.

[stanislaw]

I have made a few changes. Here are some of them:

• Your Excel code had many instance of setting something to self.= and then reading from it. I normally try to minimise the amount of methods with side-effects because it is quite hard to reason about such code long-term. To my understanding, the code in convert method is now easier to follow in terms of what happens even though it is not the most efficient performance-wise (the if header_column in parts).
• The CLI code I have also reverted a little because I don't want to couple parsing of the ReqIF and the Excel slices. I anticipate different types of configuration options for these two different import workflows so some duplication is better than splitting them back later on.

Your idea of auto-detecting the fields is a good one for now (this is why I have renamed the parser argument from "sdoc" to "basic"). However, the autodetection will not scale if I or anyone else would like to implement a full SDoc-Excel-SDoc roundtrip because then you would not know how to export the detected fields back to Excel. For this very reason, I was going to introduce the TOML config file where a field map for ReqIF as well as Excel could be specified: #587. That feature is quite easy to implement, one only needs to design the TOML schema with some scalability in mind.

Your note StrictDoc provides a support for Excel XLS on input and Excel XLSX on output. also suggests that it would be great to unify the workflow and implement the full roundtrip in the integration tests. I am not sure if I want to focus on this specific part of StrictDoc just yet. How is it for you - are you interested in having StrictDoc to import from and then export to the same Excel?

[BenGardiner]

Thanks 🥳

Your note StrictDoc provides a support for Excel XLS on input and Excel XLSX on output. also suggests that it would be great to unify the workflow and implement the full roundtrip in the integration tests. I am not sure if I want to focus on this specific part of StrictDoc just yet. How is it for you - are you interested in having StrictDoc to import from and then export to the same Excel?

Yeah... roundtripping the strictdoc requirements is something I think some teams could benefit from. But for my part I want to stop editing requirements in excel so I don't foresee putting any effort into that, sorry.

[stanislaw]

Sure! Thanks for your feedback. I was thinking of creating something like "ReqXLS" - a tool/format that enable nice-looking Excel requirements documents that are 100% compatible with SDoc and ReqIF models. I don't need this feature myself, but it could be a very useful vacation project 😄