Possible for TopicType to have multiple entries?

[buildingsmart]

Possible for TopicType to have multiple entries?

[linhard]

Yes this is already possible with the extension.xsd which is referenced by the "project.bcfp" to topics. (The idea is that you create your own extension.xsd with your own enumaration lists)

[theoryshaw]

okay, just to clarify, let's say, hypothetically the extension.xsd has the following values.

• structure
• architecture
• specifications
• daylighting
• mechanical
• technology
• data
• electrical

It would be ideal to pick and choose which ones from this list populate the TopicType field.... kinda like labels/tags in github.

It seems at present, TopicType allows for only one value.

I could be wrong here.

Ryan

[ErikPijnenburg]

@ryan, as you already mention: what you want is more a tag, or keyword. Or perhaps "discipline". I suggest to define something new and not use TopicType for this.

[theoryshaw]

@ErikPijnenburg in your comment above, did you mean 'TopicType' instead of 'TopicStatus'?

I was advocating for a modification to 'TopicType', not 'TopicStatus'.

Eitherway, I can see the value of adding another attribute (keyword, label, tag) to achieve the desired functionality described above.

[ErikPijnenburg]

YepI meant TopicType. I corrected it now.

[linhard]

Thats correct at the moment TopicType allows for only one value.
I like the idea to have multiple TopicTypes on one topic.

When we introduced this TopicType we had in mind what you see in the current extension.xsd

• Comment (which is a standard topic)
• Issue (could be a clash, with BIMSnippet)
• Request (could be a ProvisionForVoid with BIMSnippet)
• Solution (could be an opening with BIMSnippet)

but now a standard topic can be an error or a warning. and a Issue must not be a clash but can also be an instruction.
Therefore multiple TopicTypes per topic might be a good solution.

[theoryshaw]

Will also add, from my perspective and usage, we really never designate our TopicTypes as (Comment, Issue, Request, Solution). It's a level of categorization of a typic, that's not necessary for us.

It would, however, be helpful if TopicType had more flexibility. We would, on the other hand, use it for tags/labels.

Could it not be both? Perhaps keep the architecture open initially, and watch the user patterns.

Just my 2 cents.

[ErikPijnenburg]

In the current definition I see multiple TopicTypes possible. I don't think we should go into that direction. It makes understanding not easier. So I suggest one single TopicType per topic. And solve the request of Ryan with a tags or keyword field.

[linhard]

Yes i agree. How about the following

• make "TopicType" and "TopicStatus" an attribute of "Topic"
• add unbounded Element "KeyWord" to the "Topic"
• add "KeyWord" also to the extension.xsd

[theoryshaw]

sounds good. I would only vote for it be called 'TopicTag' or 'TopicLabel'. This is more in keeping with the approach used by many other issue tracking/ticketing programs.

[ErikPijnenburg]

I agree