buildingsmart / bcf-xml Goto Github PK

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.

Hi,

We have been looking at how we might be able to package color values in BCF. We have an example that is currently only useful in Revit at the moment. The general idea is that we could have a consistant color schems across softwares. These could be handled across the project or at the pset level. I don't know how to post a file on the issue so here is a link to a shared google drive folder with the example. In our testing having the additional "ColorScheme.xml" file in the file doesn't seem to cause any problems.

https://drive.google.com/folderview?id=0B8WWWkKd48yAZ0l5YjRpM0Y2eVk&usp=sharing

Regards.

Use the current date as creation date and add modified date to comment.

Viewpoint itself does not have a Guid property. However, the Markup does reference a Viewpoint with a Guid.

Hi all,
I wanted to inform you about the development of an open source BCF client, it currently interacts only with Autodesk Revit but it is set up to easily allow integration with other platforms and eventually web services.

BCFier website: http://bcfier.com/
GitHub repo: https://github.com/teocomi/BCFier

Please pardon me for reporting it here since it is not a proper issue, but I was hoping to reach out to the people really contributing to BCF.

Should the GUID of a topic really be optional as it is in the current markup.xsd ?

We should define Status in Comment to be of Type “TopicType” like is done with VerbalStatus which is of type TopicStatus". And define them as maxOccurs = 1.

"VerbalStatus" type="TopicStatus" minOccurs=“0”, MaxOccurs=“1"
"Status" type=“TopicType” minOccurs=“0”, MaxOccurs=“1"

The definition of "CommentStatus" is is never used, so can be removed from the schemes

Was wondering if we could have an open discussion around the use of 'lines'.

per the BIM Collaboration Format v2.0 Technical Documentation

"Lines can be used to add markup in 3D. Each line is defined by three dimensional Start Point and End Point."

For me, as a user, it would be more helpful if these 'lines' were 2-d annotation lines transposed over snapshot.png and/or a camera view.

On some of the BCF plugins, you're starting to see this 'markup/sketching' functionality being introduced.

Would be nice to standardize these annotation lines.

Would be an opportunity, perhaps, to start funneling entities such as IfcPolyline, IfcBSplineCurve, and IfcLine into the BCF standard.

Through RESTful services these entities could be used for real-time markup functionality, for example.

Also, for future versions of the BCF, this approach could be an opportunity to start pulling the 2d construction details drawn natively in the authoring software, through the BCF standard, to other authoring programs.

Could act as a simple, and accessible, first step toward realizing roundtrip/bidirectional functionality of the IFC standard.

The BCF 2.0 documentation should contain a section "recommended use". There are too many things in BCF 2.0 for disputable reasons which can cause different interpretations of BCF 2.0

So I suggest at least these recommendations and invite everybody to add more:

Keep relation comment:viewpoint = n:1
The Viewpoint-ID in a Comment is regarded being leading !
This is to prevent that wrong use of back-reference from viewpoints to comments can make the relation n:n. So actually comment-ID in Viewpoint could or should even better be removed from the. BCF 2.0 definition. Redundant info is often cause of trouble.

Comment status and verbal status will be phased out and are replaced by status and type on topic level. When interpreting BCF 1.0 files this is the way to do it:
a- use Status of most recent comment as Issue-Type
b- use Verbalstatus of most recent comment as Issue-Status.
When interpreting BCF 2.0 files: Verbal Status and Status on comment level should all be neglected if Status and Type are present on Issue-level

Remark: a BCF hub needs to keep track of history on its own and not by using these obsolete fields in comments.

To prevent huge viewpoints containing all GUId's of an IFC file (which we see a lot in BCF files) it should be defined that when NO components are mentioned in a viewpoint as being visible it means the whole model is visible (clipping planes can do the job to pinpoint an issue)

I miss a definition for assigning topics to responsible team-members.
This is absolutely needed for a better processing and monitoring of topics/issues.

Could be easy added to the Topic properties.

Now we agreed to define the relation comment:viewpoint as n:1 (see #28) we should remove the back-reference from viewpoints to comments from the BCF 2.0 definition. It is redundant info, complicates implementation and can only cause problems ;-)

Having a predefined list is okay, but IMHO, i'd like to be able to assign multiple values to the TopicType.

examples

• TopicType: structure, architecture, specfications
• TopicType: daylighting, mechanical
• TopicType: technology, data, electrical

Acts like keywords essentially.

In implementation, user could subscribe to these 'keywords' and be pinged when new topics are issued in their areas of interest.

Would also help, for the issuer of the issue, when they don't know who exactly to assign the issue to.

As per current visinfo.xsd, VisualizationInfo can have only one Bitmap (ISG Jira issue BCF-17: Add support for text in the viewpoints).
There can be multiple texts in a viewpoint thus can support only one text.

As the RESTful API for BCF 2.0 is currently under development we discovered that the only unique reference between a Topic and an IFC-File is the "reference" (Markup/Header/FIle/Reference).
One problem for the REST API is p.e. a
DELETE /.../file/{reference} whereby {reference} = URL
For the REST API we need to add an "ID" to the File in the Markup Schema

A BCF topic has a "CreatedDate" and a "ModifiedDate" but we has not something like a "DueDate" what means a date up to when the topic should be solved

I'm creating this issue to reach out to all interested BCFv2.0 implementers. We are arranging a BCF hackathon. If you are interested, please click this link:

http://doodle.com/ckcst3mi8zmpb4sz

This might be a version 3.0 idea but worth recording.

A snapshot (and potentially 2d markup) + textual comments, is a good step forward, but what about richer media types such as narrated video?
e.g User records a short screen capture + explanation and posts that as the 'comment' to a top.
Could be implemented as media embedded in bcfzip (a-la snapshot.png)
or as a HREF attribute of a comment which posts to externally hosted video

Topic has no Creation author and no Modified author.
To keep better track of who changed topic-properties like assign to, type, status, etc:
Although we could appoint to use the Author of oldest comment as creator of issue that is not advisable...

We better add both CreationAuthor and ModifiedAuthor to topic level, to keep better track of who changed issue-properties via BCF file workflow to and from a BCF hub.

I personally don't see why a viewpoint should have multiple comments associated with it. This would lead to have different "discussions" within the same Issue, and some users might actually use the multiple viewpoints to create something like "nested issues", which is undesirable and creates confusion.

The structure of an issue should be linear like:

• ISSUE
  • COMMENT 1 & VIEWPOINT A
  • COMEMNT 2
  • COMMENT 3
  • COMMENT 4 & VIEWPOINT B
  • COMMENT 5

And not a three structure:

• ISSUE
  • VIEWPOINT 1
  • COMMENT 1
  • COMMENT 2
  • COMMENT 3
  • VIEWPOINT 2
  • COMMENT 1
  • COMMENT 2

Version 2.0 Technical Documentation for markup.xsd says that a GUID is optional for a Topic attribute and a GUID element is required as an element of Topic. The schema only supports a mandatory GUID attribute for Topic. No GUID element is specified within Topic.

Regarding 2 PfVsTopics which lead to an OpeningTopic

UseCase:
MEP creates 2 topics (PfVs) in his MEP Software. Each of the topics has a BIM-Snippet (IFC Implementing Agreement 157)
The Architecture Software gets this 2 PfVs and creates an OpeningTopic (Solution) from that.

Requirement:
The information that these 2 specific PfVs-Topics lead to that specific Opening must be hold somewhere. MEP needs to know which of his PfVs leads to an opening

Possible Solutions:

• store the GUIDs of the PfVs on the Opening-Topic or store the GUID of the Opening on each PfV-Topic
• additionally add a comment to each PfV-Topic and change the status of them to something like "processed"

Allow for the update of an object in the original software by new/added properties that had been generates outside of it, based on an earlier export as the IFC model.

Example:
The software A exported all space to a space requirement checking tool. There, certain new property sets or properties have been added to the imported spaces (e.g. about the required equipment in such an space, or similar). Now there should be a way to send this added information back to the original authoring software. This cannot be a pure IFC re-import of the spaces (e.g. since the geometry had been changed meanwhile, or the loss of parametric information), it should be only a merge of the new properties with the existing properties of the spaces in the original software.

And this process shall allow for a user interference, maybe he would not accept all, or need to be informed about what is updated, etc.

Example:
an issue is sent for a space (using the space GUID), and the request is "accept new properties for the space", and the actual data is in the BIM snippet (the new pset as IFC(XML)).

Some elements that can have multiple values have their names in plural, while some are in singular. For example, Label is in singular and RelatedTopics is in singular. Names that should be in plural, but are inherited from BCF 1.0 we cannot change.

Is this an opportunity for standardization?...

(via the @teocomi plugin)

We are facing one problem related to the optimizations of viewpoint size (https://github.com/BuildingSMART/BCF-XML/tree/master/Documentation#optimizing-viewpoint-size).

When all components are visible and some are colored, there’s a dilemma: All components are visible, so no components should be sent, but some components are colored, so they need to be sent in the visible list. This means that all components need to be sent in the visible list.

Possible solutions for this:

1. Handle coloring and selection differently from visibility -> may lead to incompatible schemas
2. Keep as it is -> large files when all components are visible and some are colored/selected
3. Agree on reserved guids in the visible list for “all components are visible” case (and maybe other cases as well) -> leads to incompatible implementations

How can we identify whats in a BIM-Snippet ?
Therefore a reference to a schema is necessary related to the "TopicType".

How can that be done ?

For v3.0, would be nice to introduce a means by which "geometric modifications' could be transmitted.

For example, on one end, an author moves a wall as part of a proposal. On the other end, after being sanctioned by the receiving party, their respective software automatically updates the wall's location.

K.I.S.S., at first, perhaps just 'moving' and 'deleting'. Later BCF versions could accommodate more advanced geometric manipulation.

When we are implementing BCF 2.0 support, it is good to have test cases from different vendors. I have made a proposal here: https://github.com/pasi-paasiala/BCF/tree/master/Test%20Cases
Comments are welcome.

In telecon held at 2014-07-17 we discussed that the Guid in visinfo.xsd's component is not needed. It should be removed. If non-IFC identified is needed, the AuthoringToolId can be used.

In extensions.xsd
https://github.com/BuildingSMART/BCF/blob/master/Extension%20Schemas/extensions.xsd

For the TopicLabel there is an enumeration of "Spesifications"
This is incorrectly spelt which would become visible if tools start enforcing the list items.
This should at least be "Specifications"
I think it should also be just :Specification" to be consistent with other list items.
None of the other list items end in 's'

ie. see below
"Architecture"
"Structure"
"Mechanical"
"Electrical"
"Technology"

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

Not sure if this matter is relevant to the GitHub page, but I was wondering if BuildingSMART is considering to have any icon for the BCF/bcfzip file format?
I think that is something important that's still missing.

It would be nice to know exactly on which revision of a project the issue (or issuelist) was created. Since most of the issues in a bcfzip are created on the same model instance it would make sence to add it under 'project.xsd'.

Have you considered or allready build support for running BCF as a database, in same way as a chatgroup?

I mean, if running a large project with 200-300 participators, it will be a complete mess keeping track of comments, based on distributed files.

just a suggestion:
shouldn't we have a namespace declaration in Markup.bcf, Visinfo.bcf, Project.bcf:

• reserved Namespace by Building Smart
• to validate XML-Files against schema on HUB

something like:

xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.iai-tech.org/.../BCF2.0"
xmlns="http://www.iai-tech.org/.../BCF2.0"
xmlns:ex="http://myhub.eu"

xs:import namespace="http://myhub.eu"
schemaLocation="http://myhub.eu/ex.xsd"

This might be specific to @teocomi's implementation, but thought i'd put it here regardless--think it helps inform the format in general.

Matteo, for your plugin, do you plan on supporting plan/elevation views for snapshots?

Would be a huge help for us, to go beyond just 3d snapshots.

Thanks, Ryan

Are there any example bcfzip files available for this new version of BCF?

In the documentation you can read this:
"One viewpoint needs to be be named viewpoint.bcfv even in the case of multiple viewpoints."
"One snapshot needs to be named snapshot.png even in the case of multiple viewpoints."

I think for compatibility it is the best if we export the viewpoint and snapshot of the latest/newest comment with fixed "viewpoint.bcfv" and "snapshot.png" names. (Not a random viewpoint/snapshot).
What do you think?

would it be worth it to the group to convert the (BCF2 0 Technical Documentation.docx) to markdown language? or html?

That way, there can be more granularity of input.

Would potentially take on task if interested.

As the RESTful API for BCF 2.0 is currently under development we discovered that the only unique reference between a Topic and an IFC-File is the "reference" (Markup/Header/FIle/Reference).
One problem for the REST API is p.e. a
DELETE /.../file/{reference} whereby {reference} = URL
For the REST API we need to add an "ID" to the File in the Markup Schema

In a comment there is both Date and ModifiedDate but only Author and not ModifiedAuthor. So in my opinion not consistent.

Although we could appoint to use the Date and Author both for creator and last-changer (in fact the one who wrote the current version of the comment-text in the BCF file) it would be much more clear to add ModifiedAuthor.

Because it is up to BCF hub if it allows non-comment-authors to edit existing comments, I suggest to add ModifiedAuthor for the same reason ModifiedDate was added

Purpose

Consistent presentation of topics in different tools through explicit ordering of viewpoints.

Proposal

BCF allows connecting viewpoints with comments and also to have viewpoints 'floating' at the topic level. When all the viewpoints are attached to comments then the comment's date can be used to choose how to order the viewpoints when displaying them to the user.
However, the user is not able to choose a different order nor is she able to order 'floating' viewpoints so that their display order is consistent among different tools.

The following changes are proposed:

1. Add an optional 'index' attribute for each ViewPoint
2. Specifying that when ViewPoints are not indexed then the order in which they appear in the XML should be used to display them to the user
3. The viewpoint ordering and index should be preserved by a BCF compliant tool

The first ViewPoint is most important since it's snapshot is used, by many tools, to generate the thumbnail for the topic. Today, users can't choose which ViewPoint will represent the topic or change their mind if they made a mistake.

We have seen BCF files with 70.000 componenst listed in each viewpoint. Also we have seen viewpoints with 80.000 lines added to viewpoints. This makes no sense and means over 10Mb of data per viewpoint; which makes the BCF workflow unusable slow, especially when using it connected to online systems.

So I would like to make some appointments for limiting this. Does it make sense to support:
a- more then 5.000 components in a viewpoint? I suggest to limit to 5.000
b- more then 25 lines? I suggest to set max nr to 25 lines
c- more then 6 clipping planes? I suggest to set max nr on 6 clipping planes

sub a.
Software which can create issues/viewpoints should help users in their GUI to understand this and guide them to good use. Either save selected objects only or, when many objects needed: use clipping planes to explain the issue.

I have noticed that documentation Readme.md is not defining the schema (xsd files) as it is.
at least viewpoint reference in comment is missing in the document. There could be other things too.

a good read from a user (Michael McCune) in the trenches.
http://collectivebim.com/future-issue-tracking-bcf/

I suggest to move priority to topic-level. Priority at comment-level makes no sense and should be removed.

I have two problems with this in the definition:
a) It is not clear what kind of GUID to be used (Comment? Topic? or anything?)
b) A comment has it’s place in a historical list in an issue, So it makes not much sense to define a GUI where everybody can reply to all other comments or topics in that list: BCF is not meant to offer chat-possibilities. It is about Issue-management

For relations between topics we have the Related Topic-fields

Purpose

This improvement would allow different tools to safely store a mappings between models and issues. If implemented properly then when a BCF is displayed the tool will be able to confidently lookup the models related to the BCF, load them and then apply the BCF viewpoint and display the topic.

Proposal

For each File element add an optional list of custom identifiers where each identifier has the following elements:

• vendor name
• system name
• id

The various vendors and BIM servers supporting BCFs would have to keep each other's identifiers and only add/remove their own identifiers if needed

Example

In the example below, Vendor1 is used by a couple of users so there's unique identifiers for both their desktops, Vendor2 is used by another user and there's also a central BIM server that stores the models as well as the BCFs which embeds it's UIDs in each topic that is managed by it.

<Header>
   <File>
      <Filename>some file.ifc</Filename>
      <Date>...</Date>
      <Reference>....</Reference>
      <CustomIdentifiers>
          <CustomIdentifier>
               <vendor>Vendor1</vendor>
               <system>User1's desktop ID</system>
               <id>some GUID that allows finding the file in the user's desktop</id>
          </customIdentifier>
          <CustomIdentifier>
               <vendor>Vendor1</vendor>
               <system>User2's desktop ID</system>
               <id>some GUID that allows finding the file in the user's desktop</id>
          </customIdentifier>
          <CustomIdentifier>
               <vendor>Vendor2</vendor>
               <system>User3's desktop ID</system>
               <id>some GUID that allows finding the file in the user's desktop</id>
          </customIdentifier>
          <CustomIdentifier>
               <vendor>BimServer1</vendor>
               <id>some GUID that allows finding the model on the BIM Server</id>
           </customIdentifier>
      </CustomIdentifiers>
  </File>
  <File>
      ....
  </File>
  .....

[Updated]
Feature request 1: possibility to sort issues within a BCF file.
Feature request 2: possibility to sort the views (viewpoints&snapshots) within an issue.

The user needs to be able to sort these in a custom order that is not just chronological or alphabetical, for presentation purposes and much more.

This implementation for the views could be easily done by adding an ordinal field in the <xs:complexType name="ViewPoint">.
For the issues, it could either live in the "project.bcfp" file, in a new "issues.bcfi" file, or in the <xs:element name="Markup"> (probably worst approach).

under header BACKGROUND

This document describes the BFC format <<< BCF