Topic type and status

[ErikPijnenburg]

In the documentation there is no mention of TopicStatus and TopicType while in Lars' extension scheme there is. Are those meant to be in the definition ?
I would like to have them there. makes more sense then comments having a status

[linhard]

For compatibility reasons we leave the status on the comments but having the possibility to define a list of possible statuses in the extension.xsd

[ErikPijnenburg]

I understand but backwards compatibility can still be respected when adding type and status also on Topic level. You see some BCF implementations fighting with things like "the last topic verbal-status/status is regarded as Topic status/type" but that's not standardized. Perhaps something like this should be in the definition then.

When a list of possible statuses is defined in extension.xsd where to use it: in VerbalStatus or Status? And where the list of Topic Types?

[linhard]

There are still some things missing in the extension.xsd

• TopicType
• SnippetType
  but i think Lars is working on it.

statuses in extension.xsd belonging to "Status". The VerbalStatus is free text at the moment but we could also thinking about to put in the extension.xsd

I will upload this afternoon an updated version of the documentation and markup.xsd and than we can continue to discuss your very good input to that project !

[ErikPijnenburg]

Thanks for the new documentation. But still don't fully grab the idea ;-)

• In Topic we have TopicType with description <(Predefined list in “extension.xsd”)> = ok, all clear
• In comment we have Status with description: <Status of the comment / topic (Predefined list in “extension.xsd”) >
  Does this mean Comment Status is also Topic Status from the list of TopicStatus? Which one is leading? The last comment? And does it mean it became a real "status" (since before it was more a type list (Error, Info, etc) and now: Open, closed, etc.

I still vote for adding in the Topic a TopicStatus same as the new TopicType. The type TopicStatus now referes to: "-- BCF-16 Add topic status to comments" but I don not see that being used in the comment.

And phase out the Status property of comments. For backward compatibility applications (when reading BCF 1.0) can take the verbal-status of the last comment to put it in the TopicStatus. We will do the same with CommentStatus: we will read last CommentStatus (since currently it is used as Type) to use it as TopicType.

[linhard]

Ok, you are right, iam also confused

Status in BCF1.0:

<xs:simpleType name="CommentStatus">
    <xs:restriction base="xs:string">
        <xs:enumeration value="Error"/>
        <xs:enumeration value="Warning"/>
        <xs:enumeration value="Info"/>
        <xs:enumeration value="Unknown"/>

For BCF 2.0:

• is the status of the comment but should be the status of the topic
• we said we leave it there on the comment for compatibility reasons
• this status should also be in the reference.xsd but currently it is not

VerbalStatus:
In BCF 1.0 it is
xs:element name="VerbalStatus" type="xs:string" minOccurs="0"/

and we have verbalstatus like open, in progress, resolved, closed etc... and the verbalstatus of the latest comment is the status of the topic.

BCF 2.0
=> i think the reference.xsd here is not correct.
=> it should be something like xs:element name="ExtendedCommentVerbalStatus" type="VerbalStatus"/

<xs:simpleType name="VerbalStatus">
        <xs:restriction base="xs:string" >
            <xs:enumeration value="Open"/>
            <xs:enumeration value="In Progress"/>
            <xs:enumeration value="Closed"/>
            <xs:enumeration value="Rejected"/>
        </xs:restriction>

---

[ErikPijnenburg]

Yes it's confusing.
Correct me if I am wrong, to summarize:
VerbalStatus remains in Comment and contains Status ("Open", "Closed") and the one in latest comment defines TopicStatus.
CommentStatus remains in Comment, will mean TopicStatus but actually contains Type info like "Error", "Warning"
And we have a new TopicType containing the same. Why ?

Still not clear why you do add a TopicType but not a TopicStatus.

And in markup I see this:

!-- BCF-16 Add topic status to comments to know when a topic is resolved or still open --
and: xs:simpleType name="TopicStatus", etc

Please explain a bit more. thanks.

[linhard]

VerbalStatus remains in Comment and contains Status ("Open", "Closed") and the one in latest comment defines TopicStatus. => ok

CommentStatus remains in Comment, will mean TopicStatus but actually contains Type info like "Error", "Warning"
And we have a new TopicType containing the same. Why ?
=> Thats a good hint !!

While in BCF 1.0 we have status like "Error, Warning, Info" -> Status (which meant to be the TopicStatus)
In BCF 2.0 we have additionally that BIM-Snippet like " Issue, Request , Resolution" -> TopicType

But i agree that is confusing !!
"TopicStatus" and "TopicType" is not exactly the same but can be in some cases.

What can we do, because status in BCF 1.0 is also mandatory ?
@Pasi -> what do you think ?

[theoryshaw]

I agree that a topic should have a topicstatis.

I agree as well, that status property of comments should be phased out. Again, github is pretty good precedent here. To be able to put a status on every one of these comment we leave here, would be mind-numbing. :)

[theoryshaw]

for reference:

• http://jira.buildingsmart.org/browse/BCF-16
• http://jira.buildingsmart.org/browse/BCF-20
• http://jira.buildingsmart.org/browse/BCF-19

[theoryshaw]

the more i think about it, VerbalStatus seems over kill too.

When looking at github, trac, or jira as precedent here, none provide a way to 'categorize' and 'assign status' to a comments.

Maybe i'm missing something. Could someone provide me a precedent for this type of approach?

Thanks Much.

[linhard]

The current agreement that we have so far with the new BCF 2.0 is that it should be compatible to BCF 1.0 !

If for any reason we say that BCF 2.0 must not be compatible to BCF 1.0 then we have to define that first before going on to discuss the status , verbalstatus

[ErikPijnenburg]

OK, so let's define how it becomes upwards compatible:

• we introduce TopicStatus and TopicType
• for BCF 1.0 compatibility we can define: use VerbalStatus and CommentType of latest comment to use as TopicStatus and TopicType.

The current use of BCF is very different in the several app's so this could also clarify the use.

[linhard]

Yes that sounds good but i think there a view things still to discuss:

What we gonna do with the fact that Comment / Status is mandatory in BCF 1.0 ?
I think in BCF 2.0 the status must be optional then and we cannot kick it out, am i right ?

The same with the verbalstatus (which is already optional) it must reside in the schema and for me it has a big meaning relating to the history of a topic.

[ErikPijnenburg]

To keep the status and verbal-status of a comment and make them optional is fine with me. I prefer not to give that any meaning for history of topics though. I suggest to keep track of history in a different way and solve it in the GUI of BCF solutions: when a TopicStatus is changed a comment can be generated containing: "linhard changed TopicStatus from 'Active' to Resolved' on 27-10-2013, 20:35".

[berlotti]

This really is a major item in BCF 2.0. Can we decide quickly on this and process the changed in the schema?

[pasi-paasiala]

Sorry for not being active in this discussion. I think the problem with TopicStatus is that what do we do with it when we update a BCF? If you have set the the status of your topic, say "Fixed", then you get a reply from someone to the same topic and there it is "Open". Should your topic have the status "Open" or "Fixed" after this update? If we introduce the topic status, should it also have date/time assigned to it so that the later wins when updating? We have had problems in correctly updating the topic status from the comments, but at least it can be implemented so that the results is predictable.

[theoryshaw]

my 2 cents summarized...

I think having..

• Status
• VerbalStatus
• Priority (new argument here, think this might be overkill as well)

...associated with a comment is overkill, and i feel should be deprecated. Again, from what i can gather, and have seen, there's really not that many preferences, in ticketing/issue tracking or otherwise, that imbue a 'comment' with so much information.

It seems, more often then not, all this is assocated with the 'Topic' node.

2 cents.

[owensharp]

I would agree that Status should be at the Topic (Issue) level only. Comments are for ongoing discussion of a Topic and so i do not think require their own Status field, this can just be communicated in the comments and the Topic Creator (i.e owner) must review the comments, agree with proposed status and they change the Topic Status.

Experience shows that Comments are often used for 'Sub-Topics' as say discussion of a Topic reveals multiple issues to be resolved by different parties. This is a limitation of BCF1 and perhaps where some suggestions to add a CommentStatus comes from? So these 'sub-topics' can be tracked? However I would have thought that if BCF2 now supports relationships between Topics that this old workaround of using Comments to track sub-issues is no longer relevant as these can now be spun off into Topics of their own and related back to the original Topic?

out of interest, is there a diagram of the currently proposed BCF2 schema anywhere? e.g like the IFC schema diagrams. I realise BCF is quite simple, but a diagram may be useful nonetheless - particularly if relationships are being introduced

[pasi-paasiala]

The status in comments were introduced to track history and to give means to find the latest status. I don't mind to have the status at topic level, but it should also then have the time, so that when updating a topic, you can compare the time and take the latter status as topic status.

[linhard]

Yes, i agree to have time on status at topic level. If nobody raise a plea i will add it to the schema ?

[berlotti]

Perfect. Great solution!

[ErikPijnenburg]

For tracking history we should do a lot more then just a time field.. And we still would need to struggle with status on comment and/or topic level.. So I don't think it is a good idea. I would agree with Pasi if it was used a lot like that but I see no current solution doing that in the way it was meant to be... so why bother for backward compatibility.

[pasi-paasiala]

Erik, I didn't really get what you wanted to say. Is it good to have the status at the topic level? Should it have the time also?

[ErikPijnenburg]

Yes I would like to have Status (and Type) on Topic level as I argumented when starting this issue.
I don't see the need for a time stamp (unless we add that everywhere) and I would oppose the idea of keeping Status in comments for keeping track of history.

In my comment 14 days ago: for BCF 1.0 compatibility we can define: use VerbalStatus and CommentType of latest comment to use as TopicStatus and TopicType. The current use of BCF is very different in the several app's so this could also clarify the use.

[theoryshaw]

done... engage. ;)

[lbj]

I vote for keeping status on comments to assure backwards compatibility and to assure the history. I guess we also need time-stamp as there might be many comments the same day and we need a way to sort them. I don't have any strong argument against also adding the Status to the Topic level apart from it means duplicating information. Alternatively we should assure that the Status of the Topic as a whole is the status for the latest comment by making it explicit in the documentation.

[owensharp]

I think Topic Status should not be modified by any other user than the Topic Creator .. they are responsible for reviewing comments and setting Status. So I cannot set someone else Topic to Closed for example.

So Comment Status should not be used to change Topic Status in any automatic way, but maybe can be used to review in manual process?

but that's just one opinion ;)

Sent from my iPhone

On 5 Nov 2013, at 19:50, Lars notifications@github.com wrote:

I vote for keeping status on comments to assure backwards compatibility and to assure the history. I guess we also need time-stamp as there might be many comments the same day and we need a way to sort them. I don't have any strong argument against also adding the Status to the Topic level apart from it means duplicating information. Alternatively we should assure that the Status of the Topic as a whole is the status for the latest comment by making it explicit in the documentation.

—
Reply to this email directly or view it on GitHub.

[pasi-paasiala]

The topic has no creator. It only has "assigned to". To me it seems that adding the status to the topic does not add much value in the end. Comments already have time stamps, so the history and "latest status wins" things are already there.

Maybe we should add example BCFs to the repository so that the implementers can test the update functionality.

[owensharp]

i should have used the term Author, however looking again at BCF structure and implementation in several apps i can see where my misunderstanding came from - namely Solibri's 'Issue' system with ability for multiple viewpoints nested within an issue vs how this translates to current BCF1 and on to BCF2. will need to study this some more but here is not the venue to discuss this (implementation) I assume, so apologies for the diversion..

[pasi-paasiala]

Let's add at the topic level the status and modified time that gets updated when one of the topic level attributes (title, status, type, label, index, assigned to, related topics) is modified. In the update, the status is updated, if the incoming topic has a later modified time.

Modified time is not changed when a child of a topic (e.g. comment or viewpoint) is added/removed/modified.

Let's also add creation time to the topic.

[linhard]

This is implemented in: a6e5144