Allow multiple choices for a report

[jborbely]

Allowing a <report> to support one or more choices for the way the calibration data is stored is required. For example, the calibration report specifies that the calibration data is a piecewise equation (function).

I will show a few options that can be implemented in the schema to handle this situation. Suggestions for additional options are welcome.

Option 1

Add the maxOccurs="unbounded" attribute to the <xsd:choice> element. It would be implement as

<xsd:choice maxOccurs="unbounded">
  ...
</xsd:choice>

This option will allow one or more choices (any choice, so you can mix them) to be in a <report>. For example, the following structure is considered valid

<report>
  ...
  <equation/>
  <equation/>
  <file/>
  <table/>
  <equation/>
  <serialised/> 
  <file/>
</report>

Option 2

Add the maxOccurs="unbounded" attribute to every child element of the <xsd:choice> element. It would be implement as

<xsd:choice>
  <xsd:element name="equation" type="msl:equation" maxOccurs="unbounded">
  <xsd:element name="file" type="msl:file" maxOccurs="unbounded">
  <xsd:element name="serialised" type="msl:serialised" maxOccurs="unbounded">
  <xsd:element name="table" type="msl:table" maxOccurs="unbounded">
</xsd:choice>

This option will allow one or more choices but only a single choice can be repeated in a <report>. For example, the following structure is considered valid

<report>
  ...
  <equation/>
  <equation/>
  <equation/>
  <equation/>
</report>

and this is also valid

<report>
  ...
  <table/>
  <table/>
</report>

Option 2b

Add the maxOccurs="unbounded" attribute to specific child elements of the <xsd:choice> element. Perhaps it only makes sense to specify an element as unbounded as needed. It's currently required for <equation> so we only enable it for <equation>. It could be implement as

<xsd:choice>
  <xsd:element name="equation" type="msl:equation" maxOccurs="unbounded">
  <xsd:element name="file" type="msl:file">
  <xsd:element name="serialised" type="msl:serialised">
  <xsd:element name="table" type="msl:table">
</xsd:choice>

Making <file> be unbounded does not seem to be unreasonable. It's not apparent to me why <serialised> and <table> would need to be unbounded.

Option 3

Add another child element to <xsd:choice> to handle the specific situation that has occurred when trying to add an equipment to a register that has the calibration data as a piecewise equation/function.

<xsd:choice>
  ...
  <xsd:element name="piecewiseEquation" type="msl:piecewiseEquation">
</xsd:choice>

There would be a customised implementation for the type msl:piecewiseEquation. The element name <piecewiseEquation> can also be modified to something else, this is my suggestion for the name.

---

@elliemolloy @rebeccahawke Bringing you in to this issue, as you're not a watcher of this repository (so you're not automatically notified of new project activity) but your feedback would be appreciated to help get the schema into a useable state.

[elliemolloy]

I think option 1 seems reasonable. Then, it's up to the user to choose what format/s they want to input the data in.

[rebeccahawke]

Thanks Joe, this would be a good improvement. I agree with Ellie that Option 1 would work well.

[ACEVS4US]

I'm happy to go with the consensus of option 1. Thanks