v15.2 – MDG Enum Tags Shemozzle!!!

[Paolo F Cantoni]

The synch will link non-profile tags with a matching name to the profile, but won't change any tags that do belong to a stereotype (even if that stereotype is not applied)

Thanks, Eve,

I think that's what I wanted to know.  I think the use case I'm looking for is... If we create some tags directly with SQL to a specific metatype (but with random GUIDs) and then decide to use them more formally with that specific metatype as a property (and thus new items of that metatype will have consistent prefixes), the next "sync" will realign the existing prefixes so that they become "official".  Incidentally, this would move the tag from the tags page to the properties page yes?

Is that what you confirmed?

[Eve]

Yes, I expect that would work.

[Paolo F Cantoni]

Yes, I expect that would work.

Danke!

That was my observation, but my eyes might have been playing tricks on me...   

Paolo

[Paolo F Cantoni]

This is addressed specifically at Eve (or any other Sparxian).
Following the discussion on the topic, we thought "We had it sorted"!  GUID Prefix is stable for a given combination of TagName, Profile and Stereotype.  We adapted our processes and forgot about it.

Recently, we found some "drift" in prefixes.  Analysis of the prefixes shows that some prefixes are the same for multiple stereotypes.  Before we perform more extensive analyses and try to figure out what's happened, it would be good to have the statement (in bold) confirmed!

Also, Eve mentioned; "Yes, the stereotype that is relevant is not the end stereotype, but whichever one defines the property."  Can you explain further what this means in practical terms?  Could this be the cause of what we are now seeing?


TIA,
Paolo

[Eve]

Yes, the statement in bold is correct. If it wasn't, the whole mechanism wouldn't work.

My comment was about specialization of stereotypes.

Code: [Select]

stereotype A
{
   exampleProperty : string
}

stereotype B specializing A
{
}

class C stereotyped with B
{
   exampleProperty="test"
}
The exampleProperty on C comes from stereotype A, not B.

[Paolo F Cantoni]

Yes, the statement in bold is correct. If it wasn't, the whole mechanism wouldn't work.

My comment was about the specialization of stereotypes.

Code: [Select]

stereotype A
{
   exampleProperty : string
}

stereotype B specializing A
{
}

class C stereotyped with B
{
   exampleProperty="test"
}
The exampleProperty on C comes from stereotype A, not B.

Thanks, Eve,
Good to know.

I'll investigate if those stereotypes with the same prefixes are inheritors of some base.

Paolo

[Paolo F Cantoni]

Hi Eve,
We've done some investigation and we've discovered that we misinterpreted your statement about "specialization of stereotypes".  Where we have multiple levels of specialization, "the stereotype that is relevant is not the end stereotype, but whichever one defines the property" needs to be clarified to say that it is the first stereotype that defines the property "up the inheritance chain".  Thus in the code example below, it is not inherited from Z, but from A.  We thought you meant Z.  Now we understand better, it seems to be fine.

Code: [Select]

stereotype Z
{
   exampleProperty : string
}


stereotype A specializing Z
{
   exampleProperty : string
}


stereotype B specializing A
{
}


class C stereotyped with B
{
   exampleProperty="test"
}
Have we got it correct now?


Paolo

[Eve]

Yes. If you override the property EA won't create the inherited version.

Z::exampleProperty will be uniquely identified in instances of Z and all specializations of Z that don't override it.

A::exampleProperty will be uniquely identified in instances of A and all specializations of A that don't override it.