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:
@Arne: could you please create a bug that requests this feature in RMF
best regards
mark
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
On 12.09.2015 22:03, Michael Jastram wrote:
Hi Mark,
Thank you for the analysis!
I assume that the IBM DOORS parser of
the Tool Extensions is not namespace aware:
@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
On 09.09.2015 17:42, Mark Brörkens wrote:
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
_______________________________________________
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
_______________________________________________ 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 |