Dear all, when initially implementing the serializer for RMF I tweaked several parts of the EMF serialization so that it fits to the ReqIF persistence rules. Unfortunately, it turned out that this was a bad idea when it comes to xhtml and tool extensions. For those non ReqIF metamodels it is required to keep all features that are provided by EMF, which includes support for unknown metamodels (AnyType) feature maps, intrinsic and extrinsic ID handling, etc. Therefore, we need to be careful that we do not change the standard behavior for reading and writing XML that doesn’t belong to the ReqIF namespace.
For this reason I agree with Michaels proposal for checking for the ReqIF namespace instead of the xhtml namespace. In addition to Michaels proposal we might need an „else“ that falls back to the standard emf serialization behavior. regards Mark Am 23.08.2014 um 17:42 schrieb Michael Jastram <[email protected]>: > Dear all, > > Hussein and I had a technical discussion regarding the management of IDs. As > you probably know, he contributed some code in that area that ensures that we > don't have duplicate IDs in our models. We had that problem in the past, > especially when users extended the model via copy & paste (Thanks!). > > Turns out that the current implementation does too much: For instance, it > also assigend IDs to xhtml:p elements. While this is not wrong, it can still > create problems. For instance, it may create false positives when looking > for changes. > > The key logic lives in > org.eclipse.rmf.reqif10.serialization.ReqIF10ResourceImpl. For now, I > changed the logic to only consider elements from the ReqIF10Package: > > public void setID(final EObject eObject, final String id) { > final EAttribute idAttribute = eObject.eClass().getEIDAttribute(); > if ((idAttribute != null) && (id != null)) { > > // Only to this for ReqIF IDs (and not for XHTML, etc.) > > if (idAttribute.getEType().eContainer() instanceof > ReqIF10Package) { > eObject.eSet(idAttribute, id); > } > } > super.setID(eObject, id); > } > > The question to the dev group is: Is this a good solution? In particular, > Hussein suggests to turn the logic around: explicitly exclude XHTML and > continue ID management for everything else. > > Any thoughts? > > Thanks & best wishes, > > - 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 > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/rmf-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
