Specification of the Elements in the info Element

[hesrah]

Suggested changes to the info element:

• In the info element the version element shouldn’t be decimal. E.g. version name '0.4.2' is not decimal compatible.

• We prefer none of the elements are required (-> minOccurs="0") except the ifcversion element. Especially the copyright element shouldn’t be required. Copyright is an organizational/juridical/contractual question which shouldn’t be given by a technical specification.

• The author element shouldn’t make any restriction, especially no constriction to email address.

[rubendel]

• Agree to the version, should be of type string I think, or some type of pattern that forces the user to use semver type notation (I personally prefer to allow people to use their own versioning scheme).
• Also agree to the copyright, but I would replace it with a license
• Also agree to the author not having to be an email address

In addition I would like to propose to put a maxOccurs=1 on all of the elements below Info, this helps tell the tooling that there will at most be one instance of each and therefore a singular field can be used instead of a list. Assuming the idea is no to have multiple "version", multiple "author" etc...

[hesrah]

As far as I know, in a XSD file is "maxOccurs=1" and "minOccurs=1" by default. But making it explicit is good style.

[nckremer]

I also think that the default value is 1 and except for the element version, all would then be present once per info element. But the info element content (sequence) can occur several times (if I have understood the schema correctly).

[berlotti]

Made some minor updates in 0.4.4 (now online)

• version changed to string
• made some more elements optional, but 'ifcversion' and 'name' stayed required. Ifcversion because otherwise it does not work, name because it seems to make sense to at least give the set of specifications a name.
• to make it link to BCF 'assignedTo' an email address is strongly recommended. We could lose the restriction in the XSD, but would need to document that this is a strong recommendation to use a email address here

[hesrah]

I also think that the default value is 1 and except for the element version, all would then be present once per info element. But the info element content (sequence) can occur several times (if I have understood the schema correctly).

I think the info element has the (impicit) definition minOccurs="1" maxOccurs="1" and occurs only once.
The maxOccurs="unbounded" in the sequence definition only indicates the number of occurrences of the elements in the sequence (which are in turn limited to themselves).
So each element can appear once. I think the definition is as far as desired.

[hesrah]

Made some minor updates in 0.4.4 (now online)

* version changed to string

* made some more elements optional, but 'ifcversion' and 'name' stayed required. Ifcversion because otherwise it does not work, name because it seems to make sense to at least give the set of specifications a name.

* to make it link to BCF 'assignedTo' an email address is strongly recommended.  We could lose the restriction in the XSD, but would need to document that this is a strong recommendation to use a email address here

Thanks for update.

'name' element as required makes sense.

For the author element I would then separate it and not mix things up. The author element should be free text (prefered 'optional'; it makes sense to declare it in practice, but should not be 'required' by the specification).
For BCF or other exchange mechanisms there should be a separate element. 'email' or maybe something more neutral like 'contact', 'exchange channel', 'exchange interface' or something similar. However, this should not be limited to email addresses. Other mechanisms such as web services or similar are also imaginable (in the future?). Then the element content will not be an email address.

[berlotti]

This is now processed in 0.5.0