<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        font-size:10.0pt;
        font-family:"Courier New";
        mso-fareast-language:DE;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        mso-fareast-language:EN-US;}
span.EmailStyle23
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:684745808;
        mso-list-template-ids:390866874;}
@list l1
        {mso-list-id:1189222210;
        mso-list-template-ids:-532005964;}
@list l1:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I created a Jira issue so that this discussion doesn&#8217;t get lost after the release. Forcing identifiers in cases where an attribute might have been used in Lion was an unintended consequence of eliminating associations for what became structured
 datatypes.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><a href="https://ddi-alliance.atlassian.net/browse/CDI-60">https://ddi-alliance.atlassian.net/browse/CDI-60</a><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">&#8220;After the publication of DDICDI 1.0, it would be worth reviewing and clearly stating the modeling rules.<o:p></o:p></p>
<p class="MsoNormal">In Lion there was not the clear distinction between classes and datatypes. The choice to not allow associations from datatypes meant that some elements that could be modeled as attributes must be modeled as classes. This led to the unintended
 consequence of forcing elements that could be attributes to be classes.<o:p></o:p></p>
<p class="MsoNormal">Position in the CollectionsPattern is an example. Position has an &#8220;indexes&#8221; association with a Member, so it must be a class. Classes are meant to be independent entities that can take part in associations. As such they must have unique
 identifiers. This means additional overhead, which is not completely desirable.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Now that there is a notion of a Reference attribute, elements like Position could be modeled as attributes having a Reference datatype. There could be a lightweight reference datatype that is restricted to referencing only DDICDI classes
 (or even attributes with deep linking if that was more useful than confusing). This lightweight reference could also have a &#8220;semantic&#8221; or &#8220;validClass&#8221; attribute that could be helpful with validation.<o:p></o:p></p>
<p class="MsoNormal">In the case of Position, a List could even rely on the order of the Positions in the list and drop the &#8220;value&#8221; attribute, since we now order attributes. This would further simplify lists. This is a separate discussion.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">The Reference datatype is a special element. It can be part of the structure of the model. We need to be clear on how it is to be used.&#8221;<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Flavio Rizzolo &lt;flavio.rizzolo@gmail.com&gt; <br>
<b>Sent:</b> Friday, August 6, 2021 11:09 AM<br>
<b>To:</b> Hoyle, Larry &lt;larryhoyle@ku.edu&gt;; ddi-srg@icpsr.umich.edu<br>
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI after model transform<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p>That would depend on the syntax representation, in XML or JSON you can use the nesting of elements without needing further references... In any case, I lost track of how many times we went back and forth on this, I made the suggestion because I thought we
 were not identifying everything in this iteration... my bad.<o:p></o:p></p>
<p>The identifier is optional anyways, we could emphasize in the documentation that if the syntax representation of your choice doesn't need it in certain cases, then don't use it. That would create other interoperability problems since some people might drop
 identifiers even when they are really required, but I don't see any way around that since we are given tons of flexibility to the users, and with great flexibility comes great responsibility...
<o:p></o:p></p>
<p>Flavio<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">On 2021-08-06 10:57 a.m., Hoyle, Larry wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Unfortunately, anything that is at the navigable end of an association needs an identifier. This does not mean that these need to be heavily (centrally) managed &#8211; a random UUID could work for the ddiIdentifier attribute of the Identifier.
 The Position class is an example. A list needs to be able to refer to the positions of the objects in the list. If these Positions do not have unique identifiers, a saved instance of the list and its associated positions becomes unusable.<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">Since we cannot foresee future uses of existing classes in the model, all classes should have an identifier property. This is how we have been doing this for quite a while now. This is one of the primary distinctions between classes and
 structured datatypes.<o:p></o:p></p>
<p class="MsoNormal">Please let&#8217;s not get into remodeling this at this late date.<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">Larry<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a href="mailto:ddi-srg-bounces@icpsr.umich.edu">
ddi-srg-bounces@icpsr.umich.edu</a> <a href="mailto:ddi-srg-bounces@icpsr.umich.edu">
&lt;ddi-srg-bounces@icpsr.umich.edu&gt;</a> <b>On Behalf Of </b>Flavio Rizzolo<br>
<b>Sent:</b> Friday, August 6, 2021 8:40 AM<br>
<b>To:</b> <a href="mailto:ddi-srg@icpsr.umich.edu">ddi-srg@icpsr.umich.edu</a><br>
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI after model transform<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p>Yes, that's a good point Larry. The question is whether that is the case, or it's just safer to remove them from all abstract classes with the idea we'll add them in the concrete classes as necessary.<o:p></o:p></p>
<p>The pattern classes also have identifier, even in the cases in which the concrete classes shouldn't have them, e.g. keys and keymembers. I think the criteria for having identifiers is not only that they will be instantiated but also that the instance can
 live on its own and is worth referencing, which is not the case of something like keys and keymembers (besides, it would really be an overkill to add identifier, which is not light, to something like a keymember, which is essentially a pointer linking data
 points). <o:p></o:p></p>
<p>The idea at some point was to use composition to indicate when two classes formed a single whole so that the parts didn't require separate identification from the whole. They keys certainly satisfy that, since the are parts of a dataset. Position in List
 is another example. <o:p></o:p></p>
<p>Flavio<o:p></o:p></p>
<p>&nbsp;<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2021-08-06 7:56 a.m., Hoyle, Larry wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">As to the last point:<o:p></o:p></p>
<p class="MsoNormal">I would think that adding an identifier to an abstract class is done not because I would think that adding an identifier to an abstract class is done not because you expect to identify the abstract class itself, but because you intend that
 all classes inheriting from it are identifiable. A Flavio pointed out, by being abstract, a class is never intended to be used directly. It only exists to describe what properties and relationships its descendants must have.
<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">I would not remove the identifier from an abstract classes without thinking about whether all descendants are intended to be identifiable.<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a href="mailto:ddi-srg-bounces@icpsr.umich.edu">
ddi-srg-bounces@icpsr.umich.edu</a> <a href="mailto:ddi-srg-bounces@icpsr.umich.edu">
&lt;ddi-srg-bounces@icpsr.umich.edu&gt;</a> <b>On Behalf Of </b>Wackerow, Joachim<br>
<b>Sent:</b> Friday, August 6, 2021 6:42 AM<br>
<b>To:</b> DDI Structural Reform Working Group. <a href="mailto:ddi-srg@icpsr.umich.edu">
&lt;ddi-srg@icpsr.umich.edu&gt;</a><br>
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI after model transform<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">Thanks Flavio, for the things you noticed. This is helpful. My comments are below in the message.
<o:p></o:p></p>
<p class="MsoNormal">Keep checking!<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">Achim<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="mso-fareast-language:DE">From:</span></b><span style="mso-fareast-language:DE"> Flavio Rizzolo &lt;<a href="mailto:flavio.rizzolo@gmail.com">flavio.rizzolo@gmail.com</a>&gt;
<br>
<b>Sent:</b> Freitag, 6. August 2021 03:39<br>
<b>To:</b> Wackerow, Joachim &lt;<a href="mailto:Joachim.Wackerow@gesis.org">Joachim.Wackerow@gesis.org</a>&gt;; DDI Structural Reform Working Group. &lt;<a href="mailto:ddi-srg@icpsr.umich.edu">ddi-srg@icpsr.umich.edu</a>&gt;<br>
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI after model transform</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span lang="DE">&nbsp;</span><o:p></o:p></p>
<p><span lang="DE">A couple of other issues:</span><o:p></o:p></p>
<p><span lang="DE">- The &quot;refine&quot; association seems to have a unique name now, even in the non-unique names xmi. For instance, Concept &quot;refines&quot; IndividualMember. Instead, we have Concept &quot;Concept_refines_IndividualMember&quot; IndividualMember.</span><o:p></o:p></p>
<p><b><i>[JW] The name should be probably removed in the regular XMI file. The long name should be in the version with the unique association names. The background of the refine names is that some UML tools are not able to consume the abstraction stereotypes.
 They just ignore them which results in a Abstraction relationship without further specification. Using the name is a workaround. But this is confusing in a tool like EA which can consume the abstraction stereotypes. The name repeats what is already expressed
 in the specific abstraction relationship. Another workaround would be to describe the kind of relationship in the definition.</i></b><o:p></o:p></p>
<p><b><i>I will remove the names in the regular XMI file. I&#8217;ll add the long names to the version with the unique association names.</i></b><o:p></o:p></p>
<p><b><i>You could think about if the abstraction definitions could be improved in a way that the kind of relationship is clear even if an UML tool doesn&#8217;t understand the related stereotypes like refine.</i></b><o:p></o:p></p>
<p>- Identifier appears in all classes in the inheritance chains. <span lang="DE">
For instance, Activity has Identifier, and so does Step, which is an extension of Activity. However, only the top non-abstract class in any inheritance chain should have Identifiable.</span><o:p></o:p></p>
<p><b><i>[JW] I didn&#8217;t think about this.</i></b><o:p></o:p></p>
<p><b><i>I will remove the attribute identifier at all classes which inherit from a non-abstract class.</i></b><o:p></o:p></p>
<p>- Which brings me to the next issue: abstract classes should not be identifiable, should they?
<span lang="DE">They are never instantiated, so it seems pointless they hay an identifier.</span><o:p></o:p></p>
<p><b><i><span lang="DE">[JW] Absolutely.</span></i></b><o:p></o:p></p>
<p><b><i>I&#8217;ll remove the attribute identifier from abstract classes.</i></b><o:p></o:p></p>
<p>Flavio<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<div>
<p class="MsoNormal"><span lang="DE">On 2021-08-05 2:00 p.m., Flavio Rizzolo wrote:</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p><span lang="DE">Achim,</span><o:p></o:p></p>
<p><span lang="DE">A few issues I noticed on a quick review: </span><o:p></o:p></p>
<p><span lang="DE">- The definition of Identifier seems old. It says &quot;Basic object requiring identification. Elements of this type are versioned and provide administrative metadata properties.&quot; It's a datatype now, so it should probably say &quot;identifier for
 objects requiring short- or long-lasting referencing and management&quot;, or something like that. The example seems wrong as well &quot;Use for First Order Classes whose content does not need to be discoverable in its own right but needs to be related to multiple classes.&quot;.
 I suggest to remove it.</span><o:p></o:p></p>
<p><b><i>[JW] For the next transformation run, I would need the documentation of both the class attribute identifier and the data type Identifier. It could be the same definition.</i></b><o:p></o:p></p>
<p><b><i>&#8220;Identifier for objects requiring short- or long-lasting referencing and management.&#8221; seems to be good enough.</i></b><o:p></o:p></p>
<p><b><i>The suggested removal is fine with me.</i></b><o:p></o:p></p>
<p>- Some of the attributes, e.g. ddiIdentifier, uri, appear to be of type &quot;EA_Java_Types_Package&quot;.
<span lang="DE">I'm not sure how that happened. </span><o:p></o:p></p>
<p><b><i>[JW] I typed them as strings. I will look into this. This is an issue with EA and their use of UML primitives and how they express them in their version of XMI.</i></b><o:p></o:p></p>
<p>- There is a ModelIdentification datatype, right under the DataTypes package, that doesn't seem to be used anywhere.
<o:p></o:p></p>
<p><b><i>[JW] I added this already to the public review version. It is not used anywhere in the model but it can be used by any program which uses the model or its representations. This way a program can recognize with which specification and version it deals
 with.</i></b><o:p></o:p></p>
<p><b><i>This could stay on the level of the data types like currently or it could be located just below DDICDILibrary. What do you think?</i></b><o:p></o:p></p>
<p>- I was just going over the Documentation.xlsx and noticed a couple of enumerations that didn't ring a bell.
<span lang="DE">I checked and couldn't find them in the latest EA file. They are WorkflowPattern and StringStructureType. There might be others. I'm not sure where they are coming from.</span><o:p></o:p></p>
<p><b><i>[JW] StringStructureType was removed because I simplified all string data types. It is now an external controlled vocabulary. Hard coding would be too limited.</i></b><o:p></o:p></p>
<p><b><i>WorkflowPattern is not used at all. I removed it but missed to document it.</i></b><o:p></o:p></p>
<p>That's all for now. <span lang="DE">I'll keep checking.</span><o:p></o:p></p>
<p><span lang="DE">Flavio</span><o:p></o:p></p>
<p><span lang="DE">&nbsp;</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span lang="DE">On 2021-07-30 2:59 p.m., Wackerow, Joachim wrote:</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">I did the programmatic model transformation for a couple of issues we talked about. Prior to that I edited manually the EA model regarding some other issues.<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">I documented all changes in <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2F8fkxs38snd6ss2d%2FModelTransformation_2021-07-30.docx%3Fdl%3D0&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404073646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=V8VCC%2B3RCxEb5r2sSQN62BJ2CLRoixMe4tNLpW6GR7U%3D&amp;reserved=0">
ModelTransformation_2021-07-30.docx</a>.<o:p></o:p></p>
<p class="MsoNormal">The file lists also some items which need documentation. Volunteers sought.<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">While doing this work I filed a couple of additional issues:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l1 level1 lfo3">
<span class="MsoHyperlink"><a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-57&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404083641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Cp8chbaR6Qh8zqQnQyUKXEU6TcUWijM7Y8IuQvt62k%3D&amp;reserved=0"><span lang="DE">Missing
 documentation <b>CDI-57</b></span></a></span><o:p></o:p></li><li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l1 level1 lfo3">
<span class="MsoHyperlink"><a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-56&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404083641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=p54RIYX%2FA4p1KBLCZxNVRmy5D1Ux9ToTlJsGpcWSrd0%3D&amp;reserved=0">Boolean
 class attributes: should they have a default value? <b>CDI-56</b></a></span><o:p></o:p></li><li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l1 level1 lfo3">
<span class="MsoHyperlink"><a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-55&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404093636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7OoONSrcoYMzNUETJkeSULCqN%2Bsuu7%2BFy1BEbwCH3i4%3D&amp;reserved=0">Data
 type ObjectName attributes are not clear. <b><span lang="DE">CDI-55</span></b></a></span><span style="color:windowtext;mso-fareast-language:DE">
</span><o:p></o:p></li><li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l1 level1 lfo3">
<span class="MsoHyperlink"><a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-54&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404093636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=XGrNZI%2BdEXGihVSauoKs0nh40udIfIsRxVCgcsbIskY%3D&amp;reserved=0">Data
 type name &quot;SpecificationType&quot; too generic <b>CDI-54</b></a></span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span class="MsoHyperlink"><a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-58&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404103626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3VHkTJudgfAIy24ejlbSOQN8%2F8UP4McrtwMtPrDQcIc%3D&amp;reserved=0">Review
 names of enumerations and data types. Several have the suffix 'type'. <b><span lang="DE">CDI-58</span></b></a></span><o:p></o:p></li></ol>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">The new files include everything below DDICDIModels. The abstraction stereotypes like trace are maintained. Diagrams get lost in this process.<o:p></o:p></p>
<p class="MsoNormal">The new XMI files (<a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Foizidnadhqeo1s7%2FDDI-CDI_2021-07-30.xmi%3Fdl%3D0&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404103626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SMhvTHAx4%2Bwvu6oWAEnLLaRQXlMc31HU8X1cMF75SKg%3D&amp;reserved=0">DDI-CDI_2021-07-30.xmi</a>,
<a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Fsv3h4cof4i499xx%2FDDI-CDI_UniqueAssociationNames_2021-07-30.xmi%3Fdl%3D0&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404113621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VbRcpfpv%2Bbzv4xTDMt%2FCCPNNFrka7HQqjpiRh3qPELo%3D&amp;reserved=0">
DDI-CDI_UniqueAssociationNames_2021-07-30.xmi</a>) are available for download.<o:p></o:p></p>
<p class="MsoNormal">Please review. There might be issues.<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">Achim<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="DE" style="mso-fareast-language:DE">&nbsp;</span><o:p></o:p></p>
<pre><span lang="DE">_______________________________________________</span><o:p></o:p></pre>
<pre><span lang="DE">DDI-SRG mailing list</span><o:p></o:p></pre>
<pre><span lang="DE"><a href="mailto:DDI-SRG@icpsr.umich.edu">DDI-SRG@icpsr.umich.edu</a></span><o:p></o:p></pre>
<pre><span lang="DE"><a href="https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.icpsr.umich.edu%2Fmailman%2Flistinfo%2Fddi-srg&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404113621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ze5wKz4DrSzlLHYeHcrmBLg0PRmI7%2FUCo9QAD%2FpU5Kc%3D&amp;reserved=0">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a></span><o:p></o:p></pre>
</blockquote>
</blockquote>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>DDI-SRG mailing list<o:p></o:p></pre>
<pre><a href="mailto:DDI-SRG@icpsr.umich.edu">DDI-SRG@icpsr.umich.edu</a><o:p></o:p></pre>
<pre><a href="https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.icpsr.umich.edu%2Fmailman%2Flistinfo%2Fddi-srg&amp;data=04%7C01%7Clarryhoyle%40ku.edu%7C6f69d5177eaf4a2f6a8c08d958f47213%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638630404123619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=d53uw10J4cXbbDsr3r2b%2BCk%2FrmgT6584hKC48%2FQWt%2FI%3D&amp;reserved=0">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a><o:p></o:p></pre>
</blockquote>
</blockquote>
</div>
</body>
</html>