In the new schema, check whether any maxOccurs or minOccurs should be changed

[robyngit]

Decide whether we are requiring elements that could be optional, or whether we are restricting elements to one instance where it could be useful to allow multiple.

[robyngit]

Below is a summary of which elements are required, and which are limited to one in the proposed 1.1.0 Collection and Portal schemas. I think that the elements that we've decided to restrict or make required all make sense, except in the case of <choice> elements that occur within the custom search <choiceFilter> elements:

• For <choice> elements:
  • we could switch the <label> from optional to required, and just keep the requirement for one <value>. If there's no label provided, then we can label the choice using the value.
  • We could allow multiple <value> elements, instead of just one. That way the user can create a search filter that allows a user to select an option label (e.g. "Salmon") that adds multiple values to the search (e.g. "Oncorhynchus nerka", "Oncorhynchus tshawytscha", etc.)

---

Required elements

The following elements are required within the element it occurs

Collections

• within a Collection:
  • <label>
  • <definition>
• within definition <filterGroup>:
  • at least one filter element (of any filter type: e.g. <filter>, <dateFilter>, <numericFilter>, etc...)
• within <filter>:
  • <field>
  • <value>
• <numericFilter> requires at least one any of the following three options:
  • <min>
  • <max>, or
  • <value>

Portals

• within <section>:
  • <label>
• within UI <filterGroup> (for custom search filters):
  • <label>
  • at least one filter element (of any filter type: e.g. <filter>, <dateFilter>, <numericFilter>, etc...)
• within UI <toggleFilter>
  • <trueValue>
• within UI <choiceFilter>:
  • at least one <choice>
• within <choice>:
  • <label>
  • <value>
• within <option>:
  • <optionName>
  • <optionValue>
• within <image>:
  • <identifier>

Given these required elements, the most minimal portal needs only a label and a definition with one filter:

<portal>
    <label>MyMinimalPortal</label>
    <definition>
        <filter>
            <field>text</field>
            <value>arctic</value>
        </filter>
    </definition>
</portal>

---

Elements restricted to one

The following elements are limited to one of each within the element it occurs

Collections

• within a Collection:
  • <label>
  • <name>
  • <description>
  • <definition>
• within definition <filterGroup>:
  • <operator>
  • <exclude>
• within any of the filters:
  • <label>
  • <operator>
  • <exclude>
  • <fieldsOperator>
  • <matchSubstring>
  • <min>
  • <max>
  • <value> in DateFilterType, NumericFilterType, and BooleanFilterType (unbounded in TextFilterType)

Portals

• within a Portal:
  • <logo>
  • <acknowledgements>
  • <literatureCited>
• within each <associatedParty>:
  • <image>
• within <section>:
  • <label>
  • <title>
  • <introduction>
  • <image>
  • <content>
• in UI <filterGroup>:
  • <label>
  • <description>
  • <icon>
• Within any of the UI filter elements:
  • <chooseMultiple>
  • <trueValue>
  • <trueLabel>
  • <falseValue>
  • <falseLabel>
  • <rangeMin>
  • <rangeMax>
  • <value> (this is the optional value pre-set on custom search filters)
  • <matchSubstring>
  • <step>
  • and any elements that are UIOptionsType are limited to one (e.g. <filterOptions>)
• within <choice>:
  • <label>
  • <value>
  • <choiceOptions> (UIOptionsType)
• in any element of type UIOptionsType:
  • <placeholder>
  • <icon>
  • <description>
  • <image>
• in <option>:
  • <optionName>
• in <image>:
  • <identifier>
  • <label>
  • <associatedURL>

[robyngit]

By the same logic as in the proposed change above, I think it would also make sense to allow multiple <trueValue> and <falseValue> elements in UIToggleFilterType. Setting the toggle to true (or to false) could add multiple search values to the query.