Update IfcAlignment.md

[RickBrice]

Proposed language provides clarity as to the proper ordering of IfcReferent, IfcAlignmentHorizontal, IfcAlignmentVertical, and IfcAlignmentCant.

I believe that it should also be a rule that IfcReferent should be in a separate IfcRelNests relationship with IfcAlignment from the layout alignments because the represent different concepts (stationing and layouts). However, there is not such a rule currently stated.

If such a rule where to be adopted, the language proposed in this PR should be revised.

[SergejMuhic]

I do not think this is necessary. The different usage instances are already clear enough that these are two separate concepts. We could think of adding a better description to the usages though.

I don't know why it is called Object Nesting (this is the name of the concept template) since the usage is configured and was provided a better name (not important for this PR though):

And Alignment Layout:

Not sure why this one has no reference to a template. I guess we need to fix the documentation on a different level then.

[RickBrice]

The text you provided only addresses inclusion of layouts, not their order. The order is implied in several places in the specification, but never explicitly stated.

[SergejMuhic]

I disagree, an order is implied in the usage (also encoded in the mvdxml). I agree that there is no explicit text saying that but following good principles in writing technical documentation, information should not be repeated if it can be derived from images, structures etc.

If you still think this is important, this addition should not be on IfcAlignment but on the usages section, so line 75 onwards. I would say the same for the geometry informal propositions, especially in IFC4.4 when these have been finally formalised.

[RickBrice]

following good principles in writing technical documentation, information should not be repeated if it can be derived from images, structures etc.

I disagree with this - images should support and illustrate the requirements defined in text, they don't replace the need for text. But this is not worthy of further debate.

For me, the bottom line is IfcRelNests is an order collection. The required order must be clearly stated somewhere. I am agreeable with it being in the Concept Usage section 5.4.3.1.5.

[SergejMuhic]

Looking at the documentation again, The Nesting Concept template already explicitly states an ordered composition:
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Composition/Nesting/content.html

Reflecting on your request, if the configuration of the Nesting Concept Template (includes any of the subtypes) already features restrictions for various element types, then the usage documentation needs to state the cardinalities and the required order. I would propose to address all usages then, to make it consistent.

[aothms]

proper ordering

I agree that a decision needs to be made. An ordered relationship was chosen so we shouldn't be ambiguous as to what orderings are allowed. I think I would prefer to state the opposite "No ordering is imposed even though an ordered relationship was chosen to model to the profiles and referents of an alignment; future editions of the specification may impose additional requirements", but any decision is better than no decision so I'm also happy to support this.

We should probably defer this decision to IFC4.4 though (or later..) as we should be careful not affect compatibility, even with textual statements.

CC @civilx64 for a new rule when merged / decided.