Use full yaml as input format

[AMNeumann]

The input format is already very similar to yaml, so I think it would be nice to simply use yaml as the input format.

The background for my suggestion is that I want to include pseudocode listings in a Topic (using the listings package), so it would be nice if newlines were retained from the Text field to the LaTeX output.

One of the downsides of course is that lists of the form

Solved by: req1 req1

now need to be written differently:

Solved by: ['req1', 'req2']

or in list structure:

Solved by:
  - req1
  - req2

but especially the latter seems rather desirable.

I'm open to support you with a pull request, but I first wanted to run the idea by you. I could also implement a converter for "old style" files to yaml if necessary.

[kown7]

That isn't necessary, yaml has other drawbacks with escaping apostrophes et c.

For multi-line, it's on the backlog, see: kown7#20

IIRC it's already a feature if you're using the LatexJinja2 output for exactly this reason.

[florath]

Hello @AMNeumann,
thanks a lot for you suggestion.
Using YAML as input is a great idea. When I originally designed the input format back in 2007, I was not aware of this format.
As you and known7 already mentioned, YAML has some drawbacks and needs some adaptions. But I think there are a lot advantages using a wide used and standardized format.
From the source code point of view I'd be happy to get rid of the manual crafted parser and the legacy emacs mode files.
I'd be happy to include a YAML frontend into rmtoo - even better if you could also provide a conversion tool.
Kind regards - Andre

[florath]

For multi-line, it's on the backlog, see: kown7#20

Please be clear here! You are referring to a personal branch of the tool.

[AMNeumann]

I've already found the place in the code that I need to look at and thanks to the good architecture, implementing a yaml front end should not be too hard. I've got some hours this weekend and I'll try.

[kown7]

For multi-line, it's on the backlog, see: kown7#20

Please be clear here! You are referring to a personal branch of the tool.

Yes; I just wanted to point out that keeping the newlines in the output will break a lot of tests. I've tried.

[AMNeumann]

Maybe we could implement an input format switch in the config that would allow the tests to run and older projects to still compile without conversion. We could then build yaml output and use rmtoo itself for conversion. That would probably be the easiest and imho cleanest way to do this. We could start out with the txt format as default with a deprecation warning and later switch to yaml as default.

On a side note, we could also build json input without much difficulty once yaml output works.

[kown7]

Is your intention/use-case to have one yaml/json/toml file or many small ones?

[AMNeumann]

In a first step, I'm happy with many small ones similar to the current situation. Extending this to fewer files, e.g. one per topic wouldn't be hard at all, especially with yaml.

[florath]

I'd also assume: let's start simple - one file per requirement / input.

The original idea was, to support different storage 'backends' like the original text files or - which I thought about but never implemented - a DB backend. It should be possible to add new text formats quite easily (of course this was never done before).
https://github.com/florath/rmtoo/tree/master/rmtoo/lib/storagebackend

[AMNeumann]

I personally don't like database backends because with text files you can easily keep track of the evolution of requirements using a dedicated, user-selected versioning system. Also, a database backend necessarily means a user interface of some sort. This is one of the things I like best about rmtoo: I can edit my requirements over a shaky ssh connection using my favourite editor vim.

[florath]

Yes - using plain files is one use case - which is implemented and used (and I don't want to change this).
I just mentioned a possible database backend because I just thought about this and hope to implement the current text file backend in a way that it can be easily extended / replaced - now by a possible YAML backend. (Will now replace or implement this is near future.)