RefGuidlist equivalent with enums

[Guillaume]

Hi,
I need to define a tagged value on a stereotype to select one or several values. The only way to achieve this is to use a RefGuidList and set the list of value via model elements e.g. classes.
It would be nice to have an "EnumList" to select one or several values from an enumeration.

Thanks

[Paolo F Cantoni]

Hi,
I need to define a tagged value on a stereotype to select one or several values. The only way to achieve this is to use a RefGuidList and set the list of value via model elements e.g. classes.
It would be nice to have an "EnumList" to select one or several values from an enumeration.

Thanks

Hi Guillaume,

I thought (stand to be corrected) one requirement of an enumeration was that you could select ONLY one at a time.   

However, your point is taken.  You want to be able to select a specific set of members from a defined list of possible set members.
You need a "SetList" or "MemberList".

BTW, it is a requirement of set membership that you can only be a set member once in a specific set.  Does that meet your requirements?

Paolo

[Eve]

Whenever a List version of another tagged value type is suggested my response is always to use multiple tagged values. (Which I consider to be multiple values for the one property)

[Paolo F Cantoni]

Whenever a List version of another tagged value type is suggested my response is always to use multiple tagged values. (Which I consider to be multiple values for the one property)

In my view (and experience), "There be dragons!"

We have enough trouble keeping notionally single tags in check.  Something, even after a decade we haven't figured out what, (and see below) creates either identical duplicates or semantically equivalent tags - so we can't tell which are real multiples and which are spurious.

So, we early on adopted the rule that ALL tags are singular.  We wrote queries to locate and eliminate the duplicates.  Thus we could preserve the semantic integrity of the repository.  As a consequence, trying to locate the duplicate generator has dropped significantly in priority.  We suspect problems with the Tags collection mechanisms, but there is no proof.

In our case, if the set is of values that correspond to elements that we have in the repository (and we have many elements conforming to what others might see as merely Set members) then we use RefGuidLists - the repository defines the Set.

It seems to me that you only need one more Tag type to accommodate just about all requirements for Set related lists:
Type=Set;
Members=First,Second,Third;
Default=«Uninitialized»;

And bingo! most requirements are satisfied.

Paolo

[Eve]

In my view (and experience), "There be dragons!"

Maybe, but there are bearded dragons, komodo dragons and middle earth dragons.

I'd rather solve problems around displaying multiple values when a tagged value is requested by name than reporting and offering traceability when the key is a string that needs to be parsed for semantics.

I haven't seen your issues regarding duplication of tags though. I don't know what kind of dragon is causing those.

PS. Last time I remember this coming up was you requesting a 'Category'.

https://www.sparxsystems.com/forums/smf/index.php/topic,29412.msg217380.html#msg217380

[Paolo F Cantoni]

In my view (and experience), "There be dragons!"

Maybe, but there are bearded dragons, komodo dragons and middle earth dragons.

I'd rather solve problems around displaying multiple values when a tagged value is requested by name than reporting and offering traceability when the key is a string that needs to be parsed for semantics.

I haven't seen your issues regarding duplication of tags though. I don't know what kind of dragon is causing those.

PS. Last time I remember this coming up was you requesting a 'Category'.

https://www.sparxsystems.com/forums/smf/index.php/topic,29412.msg217380.html#msg217380

Quite right about the last time!  Since then I've come to realise that Categories are Sets.  So All good.  If you could just amend the feature request. 

As to the string parsing, I was surprised at how easy (and quick) it was with SQL (at least any SQL with "like" functionality)  so we've started to adopt it for some of our properties (especially those imported from external sources - where those pesky users insist on comma separated values for properties (even with CSV files)).  In effect, we've already got them and use them, what we'd like to do is to have declarative management of the values in the set (for internal modification) - which is what the Set Tag would do. 

Paolo