Referencing ambiguities

[jlkiss]

Markup element contains the relevant Topic, Comments and Viewpoints.  My questions are:

1. Why does the Comment need to have the Topic attribute? And why does not the Viewpoint have such an attribute? It is strange that the Topic and Comments are located in the same file and still have bidirectional referencing to each other, what is missing between Topic and Viewpoints. It would be better, if we eliminate these redundant references from the schema. (If this is because of BCF 1 compatibility, let’s note it in the documentation.)
2. A Markup alway has a Topic, but Comments and Viewpoints don’t necessarily exist. There are optional references from Viewpoints to Comments, which means there can be orphan Viewpoints (which have no Comments) and orphan Comments (which are not referenced in any Viewpoints). This issue can cause problems in the UI and in the workflow, because
   1. If the UI is based on the Comment list, we are not able to show the orphan Viewpoints (this is how Tekla BIMSight works)
   2. If the UI is based on the Viewpoints, we are not able to show the orphan Comments (like in Solibri)
   3. Or, all the applications should support this two kinds of views (comment and viewpoint based)

However the latter solution could be much more work for all the vendors certified to BCF 2.0 I don’t think we should choose that. Moreover I think this is not just a UI issue, but serious workflow question: it is not acceptable when different applications handle the same Markup with different logic. In my opinion we should choose i. or ii., subordinate Comments to Viewpoint (or vice versa) and keep the workflow as simple as we can.

[theoryshaw]

good question. You might have seen this already, issue #6 will help inform what i hope will be an ensuing discussion/clarification on this topic.

[pasi-paasiala]

The current schema has one to many relationship between viewpoints and comments.