Re: [rmf-dev] Corrupt DOORS TOOL-Extension section after opening ReqIF w

[Arne Noyer <anoyer@xxxxxxxxxx>]

Hi Mark!

(1) The first test resulted in a SAX Parsing Error. I have just talked to a colleague, who made the import yesterday (i did not do it myself) and also copied the TOOL-EXTENSION section from the old ReqIF file and he said, that he may also have changed the header in order to get the ReqIF file from RMF/ProR to work correctly with DOORS.

(2) In the second test, i renamed the namespace from "doors"->"renamed" and the prefix for the elements, which resulted in a notification by DOORS, when importing the ReqIF file and again, just like yesterday, that DOORS was unable to use its ReqIF configuration, which was used for the export.

I guess it looks like that the Namespace must be defined inside the Header or DOORS has a parsing error, but the name/prefix can not be changed to anything else than "doors".

Kind regards,

Arne

Am 09.09.2015 um 17:42 schrieb Mark Brörkens <mark.broerkens@xxxxxxxxx>:

Hello Arne,

the namespace prefix to namespace mapping looks ok: All namespace uris that are used in the file are mapped to a prefix.

original export from DOORS defines:
(1)
xmlns="http://www.omg.org/spec/ReqIF/20110401/reqif.xsd“ 
xmlns:reqif="http://www.omg.org/spec/ReqIF/20110401/reqif.xsd“ 
(2)
xmlns:reqif-common="http://www.prostep.org/reqif“ 
(3)
xmlns:reqif-xhtml="http://www.w3.org/1999/xhtml“ 
xmlns:xhtml="http://www.w3.org/1999/xhtml“ 
(4)
xmlns:doors="http://www.ibm.com/rdm/doors/REQIF/xmlns/1.0“ 
(5)
xmlns:rm="http://www.ibm.com/rm“ 
(6)
xmlns:rm-reqif="http://www.ibm.com/rm/reqif“ 
(7)
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance“ => not used in instance

The RMF export translates it to:
(1)
xmlns="http://www.omg.org/spec/ReqIF/20110401/reqif.xsd“ => namespace uri known by RMF, prefix hardcoded
(2)
xmlns:reqif-common="http://www.prostep.org/reqif“ => namespace uri known by RMF, prefix hardcoded
(3)
xmlns:xhtml="http://www.w3.org/1999/xhtml“ => namespace uri known by RMF, prefix hardcoded
(4)
xmlns:xmlns_1.0="http://www.ibm.com/rdm/doors/REQIF/xmlns/1.0“ => prefix derived from namespace uri
(5)
xmlns:rm="http://www.ibm.com/rm“ => prefix derived from namespace uri
(6)
xmlns:reqif="http://www.ibm.com/rm/reqif“ => prefix derived from namespace uri
(7)
xmlns:configuration="http://eclipse.org/rmf/pror/toolextensions/1.0“ => PROR Tool extensions

I assume that the IBM DOORS parser of the Tool Extensions is not namespace aware:

As you mentioned: You don’t have access to the „doors“ tool extensions if the namespace prefix is: xmlns_1.0
However, Doors gets access to these tool extensions if you copy the original XML of the tool extension back into the reqif that was exported by RMF.
In this case the tool extensions are using the namespace prefix doors: but this prefix is not registered in the header.

Doors seems to identify its tool extensions by the namespace prefix and not by the namespace uri. I think that this is a bug in Doors.

In order to check if my assumption is correct, please do the following experiments:
(1)
Remove the part 'xmlns:doors="http://www.ibm.com/rdm/doors/REQIF/xmlns/1.0“ ‚ from the header of the reqif file that was exported by Doors and try to reimport it without processing it in RMF. 

If my aforementioned assumption is correct, then Doors should be able to read the tool extension.

(2)
If you rename the namespace prefix in the file header and where the prefix is used, then Doors should not be able to read the tool extension.

Can you confirm this behavior?

Kind regards


Mark

 




Am 09.09.2015 um 15:02 schrieb Arne Noyer <anoyer@xxxxxxxxxx>:

Hello!

Thank you very much for your quick response. You find the ReqIF files attached.

I have used RMF version 0.12.0.201503190302 programmatically at first and afterwards, i downloaded the most current version of formalmind studio with RMF version 0.13.0.201505310301 and observed the same behavior.

_______________________________________________
rmf-dev mailing list
rmf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rmf-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail