buildingSMART / BCF-XML

XML specification for BIM Collaboration Format

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Release 3.0 : visinfo minOccurs="0" for Lines, ClippingPlanes and Bitmaps

emaschas opened this issue · comments

In release 3.0 - visinfo: minOccurs="0" should be added for Lines, ClippingPlanes and Bitmaps and removed from their child elements.
For example:

                <xs:element name="Lines">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="Line"  type="Line" minOccurs="0" maxOccurs="unbounded"/>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>

should be revised as:

                <xs:element name="Lines" minOccurs="0">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="Line"  type="Line" maxOccurs="unbounded"/>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>

This would be consistent with "Components" and avoid empty elements.

This is intentional, so that for implementations there's always a List element, even if it has zero elements inside.

As far as we can see, this should also be consistent with how Components are currently wrapped. Could you elaborate on where you're seeing the difference to components there?

In visinfo.xsd:
on line 10: <xs:element name="Components" type="Components" minOccurs="0"/>
on line 20: <xs:element name="ClippingPlanes" minOccurs="0">
and many other lists in that file...
I don't see what is the problem of having either no list, or if the list is present to have at least one element in it...
The code can check if the list exist (is not null) and if it exists we know it has at least one element...
Otherwise, if the list is ommitted you get a read error even if yo you don't need that data ! you increase the risk of file rejection.

@emaschas,

Regarding your point on making collections optional: you might be right that good development practice would presume that null checks for collections should always be included in the code; it is possible that the decision in the group call was a bit rushed.
My concern is that we are quite close to finalising the schema and going through all collections to change the approach might push the release back.
I think we could discuss this again for 3.1, if agreed, this would be a change that retains compatibility with the existing XML files.
I would argue that for greater compatibility we should have minOccurs="0" on both collections and their content.

Regarding your point on consistency:

  1. ClippingPlanes seems correct in release 3.0

<xs:element name="ClippingPlanes">

  1. Components follows a different pattern because - although plural - is not a collection of entities. Perhaps we should add a clarifying comment in the schema xml.

@emaschas your comment

In visinfo.xsd:
on line 10: <xs:element name="Components" type="Components" minOccurs="0"/>
on line 20: <xs:element name="ClippingPlanes" minOccurs="0">
and many other lists in that file...
I don't see what is the problem of having either no list, or if the list is present to have at least one element in it...
The code can check if the list exist (is not null) and if it exists we know it has at least one element...
Otherwise, if the list is ommitted you get a read error even if yo you don't need that data ! you increase the risk of file rejection.

Indicates you're looking at the wrong branch. Please review release_3_0. Note that components isn't a collection - it's a type containing three elements.

Sorry, you are right, I checked on the wrong release (when you switch from "Issues" tab back to "Code", git goes to the default branch).
For 3.1 I would suggest that collections are either omitted or present and non empty (i.e. minOccurs="0" for collection and not for members)

@emaschas we discussed and accepted your point.