[rmf-dev] Corrupt DOORS TOOL-Extension section after opening ReqIF with ProR/RMF

Discussion:

Arne Noyer

2015-09-09 12:19:10 UTC

Hello all!

I have exported a ReqIF file using IBM DOORS, opened it with ProR / RMF / formalmind Studio and saved it. Afterwards, when re-importing the ReqIF file in DOORS, DOORS is unable to identify, which ReqIF-Definition (DOORS Configuration for the ReqIF Export) has to be used. Thereby, it is not possible to update an existing DOORS document when the ReqIF file was opened and saved with ProR.

I have observed, that after opening the ReqIF file with ProR, there are some minor changes in the TOOL-EXTENSION section of DOORS.
Especially, a prefix "doors" in xml tags is replaced with "xmlns" like this:

Before opening with ProR:

<REQ-IF-TOOL-EXTENSION>
....
<doors:DOORS-RIF-DEFINITION>
<doors:IDENTIFIER>_a51e5f1d-f828-4207-820f-cbbe71ffa855</doors:IDENTIFIER>
<doors:MODULE-DEFINITION>
<doors:DDC-MODE>NO_DDC</doors:DDC-MODE>
<SPECIFICATION-REF>_c73b196c-5836-49c1-9d99-57a6433ba446</SPECIFICATION-REF>
</doors:MODULE-DEFINITION>
</doors:DOORS-RIF-DEFINITION>
....
</REQ-IF-TOOL-EXTENSION>

After opening with ProR:

<REQ-IF-TOOL-EXTENSION>
....
<xmlns_1.0:DOORS-RIF-DEFINITION>
<xmlns_1.0:IDENTIFIER>_a51e5f1d-f828-4207-820f-cbbe71ffa855</xmlns_1.0:IDENTIFIER>
<xmlns_1.0:MODULE-DEFINITION>
<xmlns_1.0:DDC-MODE>NO_DDC</xmlns_1.0:DDC-MODE>
<SPECIFICATION-REF>_c73b196c-5836-49c1-9d99-57a6433ba446</SPECIFICATION-REF> </xmlns_1.0:MODULE-DEFINITION>
</xmlns_1.0:DOORS-RIF-DEFINITION>
....
</REQ-IF-TOOL-EXTENSION>

I think this results in the issues when re-importing the ReqIF file to DOORS. When copying the TOOL-EXTENSION section from the file, before opening it with ProR and pasting it in the newly saved file, everything works fine, again. Please contact me, if you want to have the complete ReqIF files as an example.

Is there any way to prevent RMF and/or ProR from making such changes?

Best regards

Arne

Mark Brörkens

2015-09-09 12:52:03 UTC

Permalink

Hello,

this looks like an issues that is related to the serialization.
In order to reproduce the error, it would be great if you could send me the original file that was exported by DOORS and the file that was saved by RMF.

Which version of RMF are you using?

First analysis: The namespace prefix doors is a shortcuts for the complete namespace uri which should be registered in the header of the reqif file.
I assume that the mapping of the doors tool extension namespace uri to its namespace prefix is somehow broken.

Kind regards

Mark

Post by Arne Noyer
Hello all!
I have exported a ReqIF file using IBM DOORS, opened it with ProR / RMF / formalmind Studio and saved it. Afterwards, when re-importing the ReqIF file in DOORS, DOORS is unable to identify, which ReqIF-Definition (DOORS Configuration for the ReqIF Export) has to be used. Thereby, it is not possible to update an existing DOORS document when the ReqIF file was opened and saved with ProR.
I have observed, that after opening the ReqIF file with ProR, there are some minor changes in the TOOL-EXTENSION section of DOORS.
<REQ-IF-TOOL-EXTENSION>
....
<doors:DOORS-RIF-DEFINITION>
<doors:IDENTIFIER>_a51e5f1d-f828-4207-820f-cbbe71ffa855</doors:IDENTIFIER>
<doors:MODULE-DEFINITION>
<doors:DDC-MODE>NO_DDC</doors:DDC-MODE>
<SPECIFICATION-REF>_c73b196c-5836-49c1-9d99-57a6433ba446</SPECIFICATION-REF>
</doors:MODULE-DEFINITION>
</doors:DOORS-RIF-DEFINITION>
....
</REQ-IF-TOOL-EXTENSION>
<REQ-IF-TOOL-EXTENSION>
....
<xmlns_1.0:DOORS-RIF-DEFINITION>
<xmlns_1.0:IDENTIFIER>_a51e5f1d-f828-4207-820f-cbbe71ffa855</xmlns_1.0:IDENTIFIER>
<xmlns_1.0:MODULE-DEFINITION>
<xmlns_1.0:DDC-MODE>NO_DDC</xmlns_1.0:DDC-MODE>
<SPECIFICATION-REF>_c73b196c-5836-49c1-9d99-57a6433ba446</SPECIFICATION-REF> </xmlns_1.0:MODULE-DEFINITION>
</xmlns_1.0:DOORS-RIF-DEFINITION>
....
</REQ-IF-TOOL-EXTENSION>
I think this results in the issues when re-importing the ReqIF file to DOORS. When copying the TOOL-EXTENSION section from the file, before opening it with ProR and pasting it in the newly saved file, everything works fine, again. Please contact me, if you want to have the complete ReqIF files as an example.
Is there any way to prevent RMF and/or ProR from making such changes?
Best regards
Arne
_______________________________________________
rmf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rmf-dev

Arne Noyer

2015-09-09 13:02:10 UTC

Permalink

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.

Best regards,

Arne

Post by Mark BrÃ¶rkens
Hello,
this looks like an issues that is related to the serialization.
In order to reproduce the error, it would be great if you could send me the original file that was exported by DOORS and the file that was saved by RMF.
Which version of RMF are you using?
First analysis: The namespace prefix doors is a shortcuts for the complete namespace uri which should be registered in the header of the reqif file.
I assume that the mapping of the doors tool extension namespace uri to its namespace prefix is somehow broken.
Kind regards
Mark

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

Mark Brörkens

2015-09-09 15:42:07 UTC

Permalink

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 dont 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

Post by Arne Noyer
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.

Arne Noyer

2015-09-10 09:09:15 UTC

Permalink

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

Post by Mark BrÃ¶rkens
Hello Arne,
the namespace prefix to namespace mapping looks ok: All namespace uris that are used in the file are mapped to a prefix.
(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
(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
As you mentioned: You dont 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.
(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

Michael Jastram

2015-09-12 20:03:38 UTC

Permalink

Hi Mark,

Thank you for the analysis!
@Gordon, we have this discussion on the Eclipse RMF mailing list: To sum
it up, DOORS seems to have problems reading the DOORS Tool Extensions if
their namespace prefix changes from "doors" to something else. Can you
confirm this, or are we on the wrong track?

Best,

- Michael

Post by Mark BrÃ¶rkens
Hello Arne,
the namespace prefix to namespace mapping looks ok: All namespace uris
that are used in the file are mapped to a prefix.
(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
(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
As you mentioned: You dont 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.
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.
(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

Post by Arne Noyer
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.

Michael Jastram

2015-09-17 16:36:43 UTC

Permalink

Hi all,

I got feedback from IBM. Their parser ignores the namespace and just
looks for the prefix. It's not clear whether they will fix this (or
when), but it is recorded in their issue tracker.

@Mark: I didn't check, but does this mean that RMF changes the prefix
upon save? Maybe (as a workaround from our side) there is a flag to
tell EMF to maintain prefix names?

Best,

- Michael

Post by Michael Jastram
Hi Mark,
Thank you for the analysis!
@Gordon, we have this discussion on the Eclipse RMF mailing list: To
sum it up, DOORS seems to have problems reading the DOORS Tool
Extensions if their namespace prefix changes from "doors" to something
else. Can you confirm this, or are we on the wrong track?
Best,
- Michael

Post by Mark BrÃ¶rkens
Hello Arne,
the namespace prefix to namespace mapping looks ok: All namespace
uris that are used in the file are mapped to a prefix.
(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
(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
As you mentioned: You dont 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
(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

Post by Arne Noyer
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.

--
*Dr. Michael Jastram* +49 (162) 274 83 94 http://jastram.de
Geschäftsführer Formal Mind GmbH http://formalmind.com
Gründer rheinjug e.V. http://rheinjug.de
Project Lead Eclipse Requirements Modeling Framework
http://eclipse.org/rmf
_______________________________________________
rmf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rmf-dev

Mark Brörkens

2015-09-18 09:27:22 UTC

Permalink

Hi all,

currently, RMF does not preserve the namespace prefix.
However, we can try to enable this feature in RMF.
A first analysis has shown that we will have to add a DocumentRoot Class to the RMF metamodel that is able to store the namespace prefixes.

Some related discussions:
* https://www.eclipse.org/forums/index.php/t/131249/
* https://books.google.de/books?id=sA0zOZuDXhgC&pg=PT239&lpg=PT239&dq=documentroot+nsprefix+xml&source=bl&ots=2ILFXZ0jKv&sig=tdRLnGnrB9tvL7p8R-EXhpy2EUQ&hl=de&sa=X&ved=0CE0Q6AEwBWoVChMI_4OmlaGAyAIVpfdyCh3NUg0o#v=onepage&q=documentroot%20nsprefix%20xml&f=false

@Arne: could you please create a bug that requests this feature in RMF

best regards

mark

Post by Michael Jastram
Hi all,
I got feedback from IBM. Their parser ignores the namespace and just looks for the prefix. It's not clear whether they will fix this (or when), but it is recorded in their issue tracker.
@Mark: I didn't check, but does this mean that RMF changes the prefix upon save? Maybe (as a workaround from our side) there is a flag to tell EMF to maintain prefix names?
Best,
- Michael

Post by Michael Jastram
Hi Mark,
Thank you for the analysis!
@Gordon, we have this discussion on the Eclipse RMF mailing list: To sum it up, DOORS seems to have problems reading the DOORS Tool Extensions if their namespace prefix changes from "doors" to something else. Can you confirm this, or are we on the wrong track?
Best,
- Michael

--
Dr. Michael Jastram +49 (162) 274 83 94 http://jastram.de
Geschäftsführer Formal Mind GmbH http://formalmind.com
Gründer rheinjug e.V. http://rheinjug.de
Project Lead Eclipse Requirements Modeling Framework http://eclipse.org/rmf
_______________________________________________
rmf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rmf-dev

--
Dr. Michael Jastram +49 (162) 274 83 94 http://jastram.de
Geschäftsführer Formal Mind GmbH http://formalmind.com
Gründer rheinjug e.V. http://rheinjug.de
Project Lead Eclipse Requirements Modeling Framework http://eclipse.org/rmf _______________________________________________
rmf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rmf-dev