Issues for Mailing list of the Requirements Interchange Format V1.2 (ReqIF) Revision Task Force

To comment on any of these issues, send email to reqif-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 16013: XHTML integration does not work as expected
Issue 16014: Associations of RelationGroup are limited to XML document scope
Issue 16399: Specification inconsistencies and misspelllings
Issue 18147: Missing class description for SpecElementsWithAttributes
Issue 18148: AttributeValue should not be subclass of Identifiable

Issue 16013: XHTML integration does not work as expected (reqif-rtf)

Click here for this issue's archive.
Source: ProSTEP iViP Association (Mr. Bertil Muth, bertil.muth(at)hood-group.com)
Nature: Revision
Severity: Critical
Summary:
A key feature of the Requirements Interchange Format is the ability to exchange formatted content (e.g. bulleted lists, text with fonts applied etc.) between requirements authoring tools. 
Transporting formatted content is implemented in ReqIF by the use of W3C’s XHMTL, and the XHTML integration does not work as proposed in the beta2 version of ReqIF, rendering the format almost useless for non-trivial exchanges.


Background:
In earlier, “non-OMG” versions of the Requirements Interchange Format, XHTML had already been incorporated, but using a proprietary, customized XHTML schema. 
For better compliance with international standards, XHTML has been incorporated using a XML schema driver for the beta2 OMG version. 


As only a subset of XHTML should be included, the project group needed to incorporate so-called XHTML XML schema “modules”, which proved to be a complex task. 
Not until the implementation of a ReqIF based transformation tool, it turned out that some XHTML element definitions were not pulled in from the W3C modules, but only their XML schema types.


This currently makes it impossible to use these XHTML elements in XML documents conforming to the ReqIF XML schema.



Resolution:
Rewrite the XHTML schema driver (which incorporates XHTML in ReqIF), in a way that all needed XHTML elements can be used in ReqIF XML documents.
In other words: replace the file driver.xsd with a new version that works as expected and adapt chapter 11.4 of the specification, which shows the content of driver.xsd, accordingly.
This new version has already been created and tested by ProSTEP.

Resolution: Replace the ReqIF 1.0 driver.xsd file (dtc/10-12-15) by the revised version dtc/11-02-12, and adapt chapter 11.4 of the specification dtc/10-12-11, which shows the content of driver.xsd, accordingly.
Revised Text:
Actions taken:
February 9, 2011: received issue
March 4, 2011: closed issue

Issue 16014: Associations of RelationGroup are limited to XML document scope (reqif-rtf)

Click
here for this issue's archive.
Source: ProSTEP iViP Association (Mr. Bertil Muth, bertil.muth(at)hood-group.com)
Nature: Enhancement
Severity: Significant
Summary:
ReqIF uses two distinct ways to reference XML identifiers in its XML schema: 
1. LOCAL-REF (which is used for XML references within the same XML document) and 
2. GLOBAL-REF (which is used for arbitrary, meaning document scope or cross document, XML references).
By mistake, the XML references representing the associations of the RelationGroup type have been made LOCAL-REF references.


The consequence of the mistake is: the source specification and target specification associated to a RelationGroup instance must be contained in the same XML document as the RelationGroup instance, or otherwise the references would be broken and the XML document would not validate against the ReqIF XML schema.


Putting both the source specification, the target specification and the relation group in one XML document can significantly increase the size of XML documents.  
Even more important, it would affect almost all exchange processes between companies and their suppliers who use older (pre-OMG) versions of Requirements Interchange Format, as they have been able to exchange single specifications and relation groups separately with these older versions. 
This would be a step backwards for these companies and reduce their willingness to use tools that adopt the ReqIF standard.


Resolution:
Simply change two XML attributes in the ReqIF XML schema (lines: <xsd:element name="SPECIFICATION-REF") from LOCAL-REF to GLOBAL-REF as shown below :


Before resolution of the issue:
<xsd:complexType name="RELATION-GROUP">
    <xsd:all>
      …
      <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION">
        <xsd:complexType>
          <xsd:choice maxOccurs="1" minOccurs="1">
            <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/>
          </xsd:choice>
        </xsd:complexType>
      </xsd:element>
      …
      <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION">
        <xsd:complexType>
          <xsd:choice maxOccurs="1" minOccurs="1">
            <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/>
          </xsd:choice>
        </xsd:complexType>
      </xsd:element>
      …
  </xsd:complexType>


After resolution of the issue:
  <xsd:complexType name="RELATION-GROUP">
    <xsd:all>
      …
      <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION">
        <xsd:complexType>
          <xsd:choice maxOccurs="1" minOccurs="1">
            <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/>
          </xsd:choice>
        </xsd:complexType>
      </xsd:element>
      …
      <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION">
        <xsd:complexType>
          <xsd:choice maxOccurs="1" minOccurs="1">
            <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/>
          </xsd:choice>
        </xsd:complexType>
      </xsd:element>
      …  </xsd:complexType>


As a side effect, the XML namespace needs to based on a new date (page 84 of the beta2 specification).

Resolution: Change two XML attributes in the ReqIF XML schema dtc/10-12-14, (lines: <xsd:element name="SPECIFICATION-REF") from LOCAL-REF to GLOBAL-REF as shown below : Old text: <xsd:complexType name="RELATION-GROUP"> <xsd:all> ... <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION"> <xsd:complexType> <xsd:choice maxOccurs="1" minOccurs="1"> <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/> </xsd:choice> </xsd:complexType> </xsd:element> ... <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION"> <xsd:complexType> <xsd:choice maxOccurs="1" minOccurs="1"> <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/> </xsd:choice> </xsd:complexType> </xsd:element> ... </xsd:complexType> New text: <xsd:complexType name="RELATION-GROUP"> <xsd:all> ... <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION"> <xsd:complexType> <xsd:choice maxOccurs="1" minOccurs="1"> <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/> </xsd:choice> </xsd:complexType> </xsd:element> ... <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION"> <xsd:complexType> <xsd:choice maxOccurs="1" minOccurs="1"> <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/> </xsd:choice> </xsd:complexType> </xsd:element> ... </xsd:complexType>
Revised Text:
Actions taken:
February 9, 2011: received issue
March 4, 2011: closed issue

Issue 16399: Specification inconsistencies and misspelllings (reqif-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
§10.2 p29 Fig10.2: Identifiable-AlternativeID composition, ident back linkage is named (with multiplicity) but shown as not navigable, the §10.8.2 p39 is unclear
§10.6.2 p36 Fig10.11: EnumValue-EmbeddedValue composition, properties role name, but multiplicity is 1 -> either * multiplicity or property role name
§10.6.3 p37 Fig10.12: AttributeValueXHTML dual compositions, if treated as compositions, duplicate back linkage attributeValue role names -> better treated as attributes (similar strong composition)
§10.8.3 p40 : AttributeDefinition, on composition, specType back linkage multiplicity should be 1 (and shown as 1 in Fig10.3 p30 ) -> 1 multiplicity
§10.8.9 p46 : AttributeDefinitionSimple associations (including composition) are redundant (when implemented) with associations of concrete realizations (AttributeDefinitionInteger, Boolean, Date ...)) -> to be removed
§10.8.18 p53 : AttributeValueSimple associations : same as AttributeDefinitionSimple -> to be removed
§10.8.18 p54 : AttributeValueSimple : description and semantics are identical -> precise Semantics if required
§10.8.20 p55 : AttributeValueXHTML : already noticed -> theValue and theOriginal should better be considered as attributes
§10.8.28 p64 : DatatypeDefinitionString, maxLength attribute, spelled in lower cases, but spelled with a L upper case in Fig10.9 &10.10 -> maxLength for consistency 
§10.8.30 p66 : EmbeddedValue : description and semantics are identical -> precise Semantics if required
§10.8.31 p66 : EnumValue : misspelling in role name of back linkage to DatatypeDefinitionEnumeration, missing 'y' and 'T' shoulf be 't' for consistencies -> datatypeDefEnum 
§10.8.31 p66 : EnumValue : properties association role name while 1 multiplicity, already mentioned 
§10.8.31 p67 : EnumValue : description and semantics are identical -> precise Semantics if required
§10.8.32 p67 : Identifiable : oonstraint #2 are redundant with Identifier attribute description
§10.8.35 p70 : ReqIFContent associations : redundant composition association with RelationGroupType and with SpecType
§10.8.36 p71 : SpecHierarchy : description and semantics are identical -> precise Semantics if required
§10.8.37 p73 : Specification : description and semantics are identical -> precise Semantics if required
§10.8.40 p75 : SpecObjectType back linkage associations : redundant back linkage with SpecType, back to ReqIFContent
§10.8.41 p76 : SpecRelation : description and semantics are identical -> precise Semantics if required
§10.8.42 p77 : SpecRelationType back linkage associations : redundant back linkage with SpecType, back to ReqIFContent


=> the documentation should better be automatically generated from the UML model (document and diagrams would be consistent). Or at least, one should implement this metamodel from the spec in a tool to check the consistency.

Resolution: As this issue mentions several topics, each paragraph and the disposition for it is listed in the following table. As the disposition is either resolved or closed, this issue is considered resolved. see pages 7 - 8 of dtc/2012-11-01 for more details
Revised Text: In clause 10.8.3 “Attribute Definition”, page 40: CHANGE specType : SpecType [0..*] TO specType : SpecType [1] In clause 10.8.9 “AttributeDefinitionSimple”, page 46, CHANGE the text below Associations TO No associations. In clause 10.8.9 “AttributeDefinitionSimple”, page 46, CHANGE the text below Constraints TO No constraints. In clause 10.8.9 “AttributeDefinitionSimple”, page 46, CHANGE the text below Semantics TO Abstract base class of simple type attributes. In clause 10.8.18 “AttributeValueSimple”, page 54, CHANGE the text below Attributes TO No attributes. In clause 10.8.18 “AttributeValueSimple”, page 54, CHANGE the text below Associations TO No associations. In clause 10.8.28 “DatatypeDefinitionString”, page 64, below Attributes and below Constraints, CHANGE maxlength TO maxLength. In clause 10.8.32 “Identifiable”, page 68, below Constraints, REMOVE the line starting with [2]. In clause 10.8.34 “RelationGroupType”, page 69, CHANGE the text below Associations TO No associations. In clause 10.8.38 “SpecificationType”, page 73, CHANGE the text below Associations TO No associations. In clause 10.8.40 “SpecObjectType”, page 75, CHANGE the text below Associations TO No associations. In clause 10.8.42 “SpecRelationType”, page 77, CHANGE the text below Associations TO No associations.
Actions taken:
July 29, 2011: received issue
April 1, 2013: closed issue

Issue 18147: Missing class description for SpecElementsWithAttributes (reqif-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Clarification
Severity: Minor
Summary:
The description of the very fundamental metaclass SpecElementWithAttributes is missing in the ReqIF class descriptions sections. This is a pure editorial issue, but important to be resolved since SpecElementWithAttributes is one of the central metaclasses of the abstract syntax.

Resolution: Add a class description for SpecElementWithAttributes
Revised Text: Add a class description for SpecElementWithAttributes. Revised Text: On page 71, after clause “10.8.35 ReqIFContent”, add a new clause with the following text: 10.8.36 SpecElementWithAttributes Package: ReqIF isAbstract: Yes Generalization: Identifiable Description An abstract super class for elements that can own attributes. Attributes No attributes Associations • values : AttributeValue [0..*] {composite} The values of the attributes owned by the element. Operations No operations Constraints No constraints Tags None Semantics Any element that can own attributes, like a requirement, a specification or a relation between requirements, needs to be an instance of a concrete subclass of this abstract class. While this class aggregates the values of the attributes, the association to the attributes’ types that define the acceptable values for the attributes is realized by concrete sub classes of this class. Additional Information No additional information
Actions taken:
October 9, 2012: received issue
April 1, 2013: closed issue

Issue 18148: AttributeValue should not be subclass of Identifiable (reqif-rtf)

Click
here for this issue's archive.
Source: ProSTEP iViP Association (Mr. Bertil Muth, bertil.muth(at)hood-group.com)
Nature: Clarification
Severity: Minor
Summary:
The class description of AttributeValue states that AttributeValue is a subclass of Identifiable. This is not correct according to the ReqIF model and the ReqIF XML schema, which state that AttributeValue has no super class.


Making AttributeValue a subclass of Identifiable in the specification was simply a copy and paste error during initial specification creation, as AttributeValue instances can uniquely be identified by their related SpecElementWithAttributes and AttributeDefinition (both have identifiers).

So the proposal is: remove the Generalization relationship between AttributeValue and Identifiable in the text of chapter 10.8.12 of the specification.

Resolution: Remove the Generalization relation to Identifiable in the class description of AttributeValue.
Revised Text: In clause 10.8.12 AttributeValue, page 49, CHANGE Generalization: Identifiable TO Generalization: none
Actions taken:
October 9, 2012: received issue
April 1, 2013: closed issue