Need: Category (Tagged Value Type)

[Paolo F Cantoni]

The Enum Tagged Value Type is very useful but there are times when one needs to be able to Categorise (as opposed to Classify - by means of an Enumeration) and allow multiple values from list to be applied (similar to the distinction between RefGUID and RefGUIDList).

Can we please get a:
Type=Category;
Values=Val1,Val2,Val3;
Default=Val2;

Where more than one value in the list may be selected (and rendered comma separated).

The Default might allow:
Default=Val1,Val3;
(for example)

Reported,
Paolo

[skiwi]

+1

[Eve]

I would strongly recommend using multiple enum tagged values instead.

ie. Each one is a single value in a 0..* list.

In general it's more flexible and powerful. Even if we do need to add improved capabilities to query for multiple values in places.

As an example, I know you use shape scripts. At a guess, you're probably wanting this so a shape script can print out multiple values. But it actually means that you can't decide to convert that into decorations or similar in the future.

Using multiple tags, it would by possible to update HasTag to query on multiple values. (If it doesn't already) There's also no reason why we can't extend the syntax to get the list of values in a print (optionally specifying a separator)

Something like this:

Code: [Select]

shape main
{
  rectangle(0,0,100,100);
  print("#TAGS:category#");
}

decoration Val1
{
  if(hasTag("category","Val1"))
  {
    setfillcolor(255,0,0);
    ellipse(0,0,100,100);
  }
}
decoration Val2
{
  if(hasTag("category","Val2"))
  {
    setfillcolor(0,255,0);
    ellipse(0,0,100,100);
  }
}
decoration Val3
{
  if(hasTag("category","Val3"))
  {
    setfillcolor(0,0,255);
    ellipse(0,0,100,100);
  }
}


[Paolo F Cantoni]

Actually, Simon, the problem of shapescripts didn't really come into the original request.

In our modelling, we make the clear distinction between Classification (in the Linnean sense) versus Categorisation.  We want to be able to make the same distinction with the properties (expressed as Tagged Values).  Obviously, it would be great to have support for Shapescripts, but that wasn't the main intention.

The category TV type can be the multi-selection list we users are all looking for.

Paolo

[Eve]

My point was that multi-select tagged value types aren't a good idea. Shape scripts were just an example of how they are unsuitable.

I would recommend anyone implementing a profile away from RefGUIDList for the same reason. You can't reliably/easily determine the reverse relationship when it's a list. You can see an example of that in the traceability window. It offers the ability to show tagged value references, but it can't do that for a RefGUIDList. The performance would be an absolute killer on any non-trivial database.

Your category tagged value would suffer the same problems if you wanted to use it to drive reporting or similar.

Out of curiosity, is there a reason you are encoding a static list of categories into your categorisation instead of modeling them? These days I almost always prefer to define something in the model where possible so that it's self-documenting and easily extensible.

[Paolo F Cantoni]

[SNIP]
Out of curiosity, is there a reason you are encoding a static list of categories into your categorisation instead of modelling them? These days I almost always prefer to define something in the model where possible so that it's self-documenting and easily extensible.

Accepting that it's always best to model.  In our view (and since other users are asking for the multi-select TV, in the view of others) you may want to be able to summarise a set of relationships into a single value⁽¹⁾.  Also, we currently have a policy of not allowing multiple TV with the same name, it allows us to clean up the TV list when things go awry.

Accepting that with performance, "you pays your money, you takes your choice"; we are prepared to pay the money.  Since RefGUIDList is allowed, other lists should be allowed.

Paolo
⁽¹⁾As you're probably aware, I'm a promoter of visualising relationships especially when hidden as properties.

[skiwi]

Paulo, you are absolutely correct that it is categorisation I am looking for.
Simon, I agree modelling both Classification and Categorisation is best.


But here's the thing you can help me with...


My scenario is that I am managing requirements.
I must be able to generate a view of the requirements model as a word document.
For example:

• A requirement has a classification 'requirements level' (e.g. Must, Should, May)
• A requirement has a category 'platform' (e.g. IaaS, PaaS, SaaS)
• A requirement only has one 'requirement level', but may apply to more than one 'platform'.

In the document I must be able to display the requirement's requirement level, and the platforms the requirement applies to.
I must be able to select the contents of the document based on platform.
For example the requirement is presented in a tablular format, with columns for

• Requirement Id (we use Alias)
• Requirement name
• Requirement description (Note)
• Requirement level (?)
• Requirement platforms (?)

Can you point me to an exemplar of how I can achieve this?

[Glassboy]

My scenario is that I am managing requirements.
I must be able to generate a view of the requirements model as a word document.
For example:

• A requirement has a classification 'requirements level' (e.g. Must, Should, May)
• A requirement has a category 'platform' (e.g. IaaS, PaaS, SaaS)
• A requirement only has one 'requirement level', but may apply to more than one 'platform'.

I have a similar requirement.  I've been trying to use keywords for a category but I don't seem to be able to expose the keywords in any meaningful way.

[skiwi]

I can select by a substring in Keywords to include or exclude packages and (I think) entities in the gernated document view. (See link).
You can insert the Keywords field in generated documents.

[Glassboy]

I can select by a substring in Keywords to include or exclude packages and (I think) entities in the gernated document view. (See link).
You can insert the Keywords field in generated documents.

It doesn't seem to be visible from places like the specification manager.

[skiwi]

Ah, yes, I haven't been playing in that area.