In the SpecRelation section, the definition of the source and target fields for Associations is vague. There is no clear guidance in the standard for how the source/target fields map to the supplier/client relationship defined in UML. This can lead to inconsistencies in handling between tools. Consider a scenario in which you have a software requirement that derives from a product requirement. In UML, the product requirement is the supplier and the software requirement is the client (relationship would be an arrow from the software requirement to the product requirement with a dervieRqt specification). How should the export look for the SpecRelation in regards to the source and target fields?

On page 57, there is the following text:
"The location of an external object MUST be specified via the data attribute.
The data attribute MUST either contain:
a) a URL relative to the location of the exchange XML document, or
b) an absolute URL.
Case a) MUST be supported, case b) SHOULD be supported."

However, case b), the absolute URL, has proven to be not relevant and even problematic in practice.

Should the import tool try to “download” the file from the URL and insert the file into the correct requirement in the RM-Tool?
This is potentially problematic if the URL points to a location that is not secure (somewhere on the internet) or if the executing user has no access to the URL (it is likely only the exporting user has access, not the importing user)

Should the import tool insert a URL into the requirement’s text (i.e. transformed the <object> reference into a text reference) and not try to actually download the file?
This is potentially problematic because the users on the importing side may have no actual access to the file, meaning the information is incomplete

So the proposal is: only allow relative URLs. This is what most ReqIF tools use anyway.

We need to import about 100 ReqIFs from a supplier working with Polarion.
Currently the ReqIFs do not contain RelationGroups which are expected from our WIndchill Requirements Connector 4.2 and Windchill RV&S 12.5 to build the links/traces (according your spec).

Do you know a workaround/skript to add RelqtionGroups into an existing ReqIF if they are missing?
Any other idea?

All our attempts to get help from PTC, PTC Community, Polarion experts , ... failed up to now.

The accuracy attribute for DatatypeDefinitionReal does not indicate what it measures or what the units are. It might be understood as the size of the Real data type in bits or bytes, or the length of the mantissa, or the number of bits or digits that can be represented without loss of accuracy, or perhaps other measures of floating-point accuracy.

Clause 10.8.20. mentions the XHTML modules that need to be supported.

Among them is the so called "XHTML Basic Tables Module".
In comparison with the "XHTML Tables Module" that exists as well, it contains less XHTML elements for tables.

The choice to list only the XHTML Basic Tables module was intentional.
The intention was to simplify the development of ReqIF importing tools, especially if the target requirements authoring tool is not web based.

The standard ReqIF XML schema for inclusion of XHTML is driver.xsd.
However, driver.xsd mistakenly references the XHTML Tables Module.

Proposal: fix this by adapting the driver.xsd. This should be a one-line change.
This will establish consistency with the ReqIF standard document.

Figure 8-1 has a low resolution which makes text on it hard to read.

Section 10.8.3 indicates that AttributeDefinition specializes AccessControlledElement, which in turn specializes Identifiable, but this not reflected in Figure 10.3.

There is no text after the "Generalization:" label in the EmbeddedValue section.