feat: keep SPEC-RELATION and RELATION-GROUP attribute values

[fNBU]

@stanislaw, one part of this fix (SPEC-RELATION) is an ordinary bug fix, but the other part (RELATION-GROUP) reads and writes an element the bundled reqif.xsd rejects. The latter needs your consideration.

SPEC-RELATION

ReqIFSpecRelation modelled <VALUES> as values_attribute, a single value, and the parser's loop breaks after the first child, so a relation with two values kept only the first. That loop handled just STRING, INTEGER and XHTML, raising NotImplementedError on the other four kinds, so on current main a SPEC-RELATION carrying a BOOLEAN, DATE, REAL or ENUMERATION value does not lose data, it fails to parse at all.

RELATION-GROUP

ReqIFRelationGroup had no field for <VALUES> at all, so those values were dropped on parse and never written. Adding them runs into the schema:

complexType	<VALUES> permitted?
SPEC-OBJECT	yes
SPEC-RELATION	yes
RELATION-GROUP	no

The asymmetry is a defect: the spec PDF's MOF model (10.8.33) defines values on RelationGroup and the XSD omits them. From the prostep ivip ReqIF Implementation Guide v1.8, section 2.11 (p. 20):

Due to a bug in the current ReqIF XML schema, it is possible to assign a RelationGroupType (including AttributeDefinition elements) to a RelationGroup element, but it is not possible to assign AttributeValue elements to the RelationGroup. As this may lead to inconsistencies, the current recommendation is not to add any AttributeDefinition elements to a RelationGroupType instance.

That advice is aimed at whoever authors the content, and says nothing about what an importing tool should do with a file that already contains the element. #214 (merged as cd6c4ad) also added attribute_definitions to ReqIFRelationGroupType, so reqif can already express a relation group type with attribute definitions but cannot carry the matching values. That is the inconsistency 2.11 warns about, and closing it the other way would mean reverting #214.

Validation is unaffected: validate --use-reqif-schema still reports one schema issue on such a file and zero on a conformant one.

Permissive on import, warning on export

Sections 2.1, 2.3 and 2.13 of the guide all ask importing tools to be forgiving about what they read and keep the strictness on the export side. Refusing to parse the element would make reqif less compliant with the guide, not more, so nothing warns on parse.

Export is where the strictness belongs. So unparse logs a warning naming the group, once per group per write. A caller who adds VALUES to a group that did not have them hears about it, then decides whether to ship an XSD-invalid file. They know more about their use case; a library that refused to write the element would make that call for them.

Callers who have made the call can silence the warning the usual way, with no change to the output:

logging.getLogger("reqif.parsers.relation_group_parser").setLevel(logging.ERROR)

Tests

test_spec_relation_parser.py covers mixed values surviving parse and unparse (including the previously fatal BOOLEAN) and the deprecated accessor. test_relation_group_parser.py is new, the first unit coverage for that parser: values survive, a group without values does not grow a VALUES element, and the warning fires once, names the group, stays off during parse, and can be suppressed. invoke check is clean, integration 78 passed with 1 unsupported and 0 failed.

If you'd prefer hard refusal to emit xsd-invalid (but spec-valid) reqif, I can implement that (our project will have to monkeypatch around it).

[stanislaw]

This seems to be fine as you suggested. It is a good compromise given the bug in the xsd spec.