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 <[email protected]>: >> >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/rmf-dev
