[Feature]: Readable labels for requirements: detect the id and text attributes  #68

What type of issue is this?

• Bug report
• Feature request

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of the reqifviewer
• I have searched open and closed issues to ensure it has not already been reported

Description

In the Subset026 sample the specification tree reads "16", "292230", "134", "3275"...: the label falls back to the first attribute value, which there is an internal Word trace id. The meaningful id (requirementID = "3.4.2.2.2[2].[f]1") and the text are in the file but not used.

Proposed heuristics, in order: the attribute names from the ReqIF Implementation Guide (ReqIF.ForeignID for the id, ReqIF.ChapterName for headings, ReqIF.Text for the text); attribute names containing "id"; the first XHTML attribute for the text.

Acceptance criteria

• Per spec type, the viewer picks an "id" attribute and a "text" attribute using the heuristics described above, and a "heading" attribute for chapters.
• The user can change the choice per spec type; it is remembered per file (browser storage).
• Every list, tree, search result and trace uses these labels; internal identifiers appear only in the inspector.
• Tested against both sample files (the Subset026 tree shows "3.4.2.2.2[2].[f]1"-style ids and the text, not "16").

Steps to Reproduce

Load requirements-and-objects.reqifz or ProR_Traceability-Template-v1.0.reqif (reqifviewer.Tests/TestData) and look at the pages mentioned above.

System Configuration

• reqifviewer version: 6.1.0 (development, with [Refactor] Blazor Blueprint app shell and Blazor Web App hosting #56)
• Environment (Operating system, version and so on): Windows 11, Chrome
• .NET Framework version: .NET 10
• Additional information: Plan item R-02 of the viewer improvement plan. Size: M.