StrictDoc Office Hours - Need feedback

[stanislaw]

Hi everyone,

I'm considering introducing StrictDoc Office Hours to provide a dedicated time each week for discussions about StrictDoc's roadmap, features, and implementation details. The goal is to connect with the StrictDoc community, answer questions, and gather feedback directly from users and developers.

I can dedicate one hour per week for these sessions, but I'm facing a few challenges:

• Given the time zone differences (Europe/US), I want to find a time that works for as many people as possible.
• I don't know how much interest there is for such a call. From my side, I know that some of the existing very large GitHub issues could benefit from being discussed in-person.
• An option to keep things flexible, I'm thinking of alternating the time slot every other week to accommodate different schedules.

Some open questions:

• For the meeting itself, should I use Discord call or a Google Meet link? Discord would be nicer but not everyone uses it.
• Should I create a Google calendar which everyone can subscribe to?

I'd love your input on the following question below.

Please vote and share any thoughts or preferences in the comments. If you have ideas for alternative formats or topics for these sessions, I'd love to hear them!

Thanks for your time and feedback!

[stanislaw]

cc @thseiler @haxtibal @mplum @johanenglund @richardbarlow @nogjam @fkromer @elfman2 @RobertoBagnara @gioboske @dahbar @vik378 @nicpappler @BenGardiner @gioboske

[stanislaw]

cc @joergmis

[BenGardiner]

Nice idea. I support both use of discord and creating the Google calendar item.

I voted on good slots.

[richardbarlow]

I think this is a great idea! There's a couple of us here at gaitQ (UK) who would be interested in joining a call every now and again. We might not be able to join every week, so it might be helpful if there was a rough agenda (just a couple of bullet points for areas of discussion) distributed in advance so that we can plan appropriately.

We have a slight preference for Google Meet, since it doesn't require an account. We use MS Teams day-to-day (unfortunately), but I appreciate that you probably don't want to use that if you're not already trapped in the ecosystem.

Having a Google calendar might be a good way to disseminate the agenda?

[fkromer]

I‘ve 🗳️ as well

[RobertoBagnara]

This is a great idea. I voted for the option that, on average, would work best for me, but my real problem is I am overbooked. Other slots are also feasible from time to time. OT: I am currently teaching a class of 32 MSc students and they use StrictDoc.

[stanislaw]

Thanks to everyone who answered so far (11 votes). I give it another day or two and then create a calendar and set a date for the next week's first hour.

It is not easy to come up with a time slot that would work for everyone. But these two got most votes:

• Tuesday 5 PM CET / 9 AM PST (27%)
• Thursday 4 PM CET / 8 AM PST (27%)

A good compromise could be to do both slots and have them each arranged bi-weekly. Let's wait for more votes and see if the picture changes.

---

We might not be able to join every week, so it might be helpful if there was a rough agenda (just a couple of bullet points for areas of discussion) distributed in advance so that we can plan appropriately.

By default, I'll use the office hour slots to work on StrictDoc-related tasks if no one joins. In this case, there will not be a set agenda. However, if we agree on a specific topic in advance or if someone joins, we can discuss whatever is needed and plan a topic for the following week. I'm not sure what to expect, but working on StrictDoc during these hours feels like a good default. If anything specific comes up, I'll always update the meeting invitation with an agenda.

There are two things in action:

• The development time of the StrictDoc core team and its contributors is a limited resource.

• Users often request features that are unrelated to each other within StrictDoc's functionality. Just a few examples:

  • Requirements verification functionality. Reading JUnit XML and other test report formats. Generation of verification reports.
  • Versioning requirement nodes with VERSION. A corresponding Impact Assessment screen for change management.
  • Solid interface between Excel and ReqIF, SDoc and ReqIF, Excel and SDoc, SDoc and markdown, etc.
  • Supporting relations to external resources such as URL or other tools.
  • Making StrictDoc read/write ReqIF natively.
  • Making StrictDoc read/write SPDX natively.
  • Supporting other formats such as Markdown, Markdown+XML, AsciiDoc, etc.
  • And many-many other things.

I am creating a small presentation deck to outline the 2025 Q2 topics and backlog. I'll share this deck with everyone to highlight what @mettta, the contributors, and I are working on. There's always a list of key topics we focus on, with some room left for additional features and improvements. The goal is to crowdsource the roadmap, prioritizing what makes the most sense for all users – especially active users and contributors.

[stanislaw]

Hello everyone,

This is the final update in this thread. With the 12 votes so far, I am setting up two bi-weekly slots:

• Tuesday 5 PM CET / 9 AM PST (one week)
• Thursday 4 PM CET / 8 AM PST (the other week)

The first meeting will happen tomorrow: Tuesday 5 PM CET / 9 AM PST. There is no specific agenda but check the slide deck for some inputs.

StrictDoc 2025-Q2 slide deck

I have summarized the most relevant things with this slide deck:
https://docs.google.com/presentation/d/1iBleZi_l6fBP6zFK6wQHm-nX9V_DcwtgtZ3VSwahy4o/edit?usp=sharing

StrictDoc mailing list

I have already invited some of you. In case you haven't received an email, please join: https://groups.io/g/strictdoc. The slide deck gives some information about the mailing list.

Thanks to everyone for voting and giving your feedback.

[richardbarlow]

This sounds excellent. A few of us from gaitQ will hopefully join around 5:30 PM CET tomorrow.

Would it be possible to provide an iCal link to the calendar too, so that it's possible to add to calendar systems outside of the Google ecosystem (https://support.google.com/calendar/answer/37083?hl=en#zippy=%2Cshare-a-link)?

[stanislaw]

@richardbarlow,
Could you try this link and let me know if it works as expected:
https://calendar.google.com/calendar/ical/9e52bdb79398efa1c138c5938a54d48918b2858a9564f7326477879ec27c34b3%40group.calendar.google.com/public/basic.ics
?

[richardbarlow]

@stanislaw, that worked perfectly. Thanks!

[fkromer]

@stanislaw I'm not sure if this it the right point to raise this question: A common challenge w.r.t. requirement traceability is to link specific diagram elements in modeling tools (e.g. in Enterprise Architect) to the implementation in source code. In my particular case it relates to EA. I could think of that the methodology could be generic however. Do you have some real world experiences with EA or other modeling tools?

[vik378]

Hi all, I tried to write a tiny reply but there is a lot of context, so here is a short summary first

TLDR: if EA speaks python or can be automated and called on change events, you can have a headless model export and templated content derivation process - mixed-authority approach with CI-CD is a way to go. You basically feed the magic with your current StrictDoc project repo, a model snapshot + a derivation template and let it patch the affected .sdocs with new model-derived content + update images. If we bring the referenced object / object tracker concepts into StrictDoc one day this could be more fancy / closer to what we have with Polarion now. happy to share some thoughts on that. We made it work with Capella + Polarion (and Gitlab for model change control and CI), here is a little demo: https://www.youtube.com/watch?v=LQWuaNvfBS4&t=1276s

More details:
We use Capella (free, open source MBSE solution - much easier than EA yet sufficient IMHO) mostly because of the ARCADIA methodology. It helps us to keep a clean yet well traced split between the problem space / what a system needs to do as a black box and the solution space - how the system will do it (logical architecture) and how we will make the system - physical architecture with integration level details (physical / software / deliverables).

Unlike with UML / SysML where you focus on drawing pictures with ARCADIA we focus on building up and (re)using models where objects on their own matter more than individual diagrams. In practice that would mean that our sub-system specification document would be made based on a model subset that provides information about a sub-system (logical component) object, its functions and functional interactions (objects too) and interfaces (again, objects). Our interface specification documents will also be derived from the same model and even the same objects. Every object / interaction also acts as an anchor for requirements (derived from, allocated to, realized by, etc). This way, a system function in a model could be further specified by specific performance requirements, what outputs should it produce and under what conditions. And for sure you can further refine those requirements with even more model objects. You know, "all models are wrong but some are useful" so we are trying to focus on the useful bits and don't model things that we don't benefit from in our deliverables.

Speaking of deliverables, what matters at the end in our case is paperwork, documents in all forms and shapes - system specs, solution concepts, interface specs, test specs. We made transition from models to documents seamless but unfortunately we rely a lot on Polarion as our main RM / ALM tool. I can complain about it for hours but they also got some things right. The way we get our requirement documents to co-exist with models is by using engineering CI-CD and applying a so called mixed-authority approach to ownership of in-document content - some parts of a document and most of its structure is derived from the model through a template and some parts are yours to edit locally within an RM tool of choice.

When it comes to StrictDoc - we saw an opportunity to decrease dependency on commercial RM tools with StrictDoc starting with basic use-cases like publication (read only access to navigable content) and review. We made an assessment to figure out what concepts are missing in StrictDoc to make it compatible and also what concepts in general we were missing in Polarion (coming from DOORS). And we also made a little PoC to see it in action with StrictDoc that looked promising as well. But unfortunately we had to pause all that due to uncertainties related to reorg and resource freeze. Lets see - it might be that this will be picked up again by the EU Rail Research community in the near future - they have the same challenge of scaling up access to model-derived mixed authority documents that are stuck in Polarion.

If you'd like to do something like this with EA and StrictDoc feel free to use our code for inspiration: https://github.com/DSD-DBS/py-capellambse (API for headless model access); https://github.com/DSD-DBS/capellambse-context-diagrams (auto-derived diagrams); https://github.com/DSD-DBS/capella-polarion (Capella-Polarion bridge)

[stanislaw]

Thanks @vik378 for sharing your perspective with a perfectly thorough answer!

One note is that these very nice developments are possible because there is a large company behind them with the whole team of Python and other programming languages pros on board. And, as always, even then there can be some resource issues.

I am curious to know if some of this work could be done incrementally, raising the capability level slowly, with each increment being meaningful. For this, I am missing access to EA/Polarion/Doors/Capella at work, so we would need a champion to collaborate on this strongly.

[fkromer]

@vik378

TLDR: ...

As far as I know the Add-in & Scripting capabilities of EA are legacy Windows specific any other than modern and pretty limited:

• JScript (Microsoft legacy ECMAScript dialect)
• VBScript (deprecated programming language)
• JavaScript

It seems like one can use pywin32 on a Windows machine running EA as well. (To be honest not what I'm looking for.)

What Python API are you referring to?

More details: ... Unlike with UML / SysML where you focus on drawing pictures with ARCADIA we focus on building up and (re)using models where objects on their own matter more than individual diagrams.

That's exactly what I'm looking for in modern system engineering for distributed cyber physical systems (my current environment). In case the only thing one needs to care about is security (not safety) it's even possible to use plantuml diagrams or other lightweight tools which allow hyperlinking. This way it's easy and pretty agile to link from diagram objects and interfaces to "objects" in Figma designs, Jira tickets, Confluence pages or whatever other hyperlink-able source of requirement you use. This one-way link is usually sufficient. It's no possible to link single "objects" in plantuml diagrams to other tools. A two-way linking would be even better but I don't know a lightweight modeling tool which allows this. In comparison the development workflow with EA feels like a massive overshoot and like traveled back in time into 2000. A well-intentioned warning w.r.t. EA: If one wants to enable inline links into EA diagrams from other tools it's not possible to use the complete language (e.g. interfaces) cause they don't allow it. As workaround you need to use other diagram objects (which violates the SysML and UML spec actually).

I'll consider Capella in future projects for sure!

If you'd like to do something like this with EA and StrictDoc feel free to use our code for inspiration:

python4capella looks interesting as well.

[vik378]

@fkromer, one of the reasons why we migrated from something SysML1 land (PTC Modeler it was for us, very similar to EA - an old Windows thing) to Capella was the openness of the model. The model is XMI on its own, the metamodel is open and public, so you can work with the model even without Capella itself. But JavaScript sounds good.

That brings us to "What Python API..?" - https://github.com/DSD-DBS/py-capellambse is basically a headless python-only Capella implementation based on lxml which makes it fast enough (yet Martin works on a side-project to shift some of the Python stuff into Rust and make it even faster). Headless was the key thing for us since we were able to run things in CI/CD. It is a key enabler for our model-centric approach to specification consistency - one (or many federated) models, many documents and derived product.

Python4Capella is a plugin for Capella itself that allows running Python code within Capella and provides somewhat simplified access to model elements. There is also a funny story behind that - when we told "somebody" that we were about to open-source py-capellambse, that somebody told us that they just contracted "somebody else" to develop exactly that (Python4Capella) - so you can call it a sort of open source race condition 😄 But it happened to be not the same thing at the end - the usecases are quite different. One thing that we found not so cool about it was dependency on Eclipse EASE.

The story of hyperlinking objects from Jira tickets and Figma sounds a bit similar to OSLC story, there is a solution around Capella for that too. What I find tricky about that approach is the effort for reference maintenance (do you always link to head revision, if not how do you up-version your links). With surrogate object approach this pain is outsourced 😄

[fkromer]

Thx a lot for those hints. I'd prefer py-capellambse (no Eclipse EASE dependency, CI/CD compatible) over Python4Capella as well. W.r.. OSLC I totally agree. Jira provides an API for integration which allows getting epics and issues by uids. Figma provides an API for integration as well but I do not know if it's possible to get design elements by uid. In both tools versioning could be problematic if "object references" cannot be identified by uid + a version identifier.

[stanislaw]

Thanks to everyone who attended the first meeting. It turns out that Google Meet has auto-ended it at 18:00.

The meeting notes will be kept here from now on:
https://docs.google.com/document/d/1KqYmnS2pSmZhUgGzqAa62SXE_lgbbe-KBzHn_FJr35U/edit?tab=t.0 (I will add a few diagrams and notes just now for completeness)

@richardbarlow I am not sure if the meeting ended late enough. My main message regarding StrictDoc's own quality was: let us know which artifacts you / your company would like to see from StrictDoc, and we will support.