Under Community Review

We don't know if and when we'll revisit the idea, but we've previously explored the possibility of exposing some of the advanced schema constraint options (XSD schema facets) in the User Interface.

For min/max constraints on a multivalue select, it might look something like this.

Aside from multi-value, there's a relationship between "Mandatory" and "Minimum" that we considered in the design. Technically the Mandatory boolean option could be removed as it would be represented in a minimum of 1 (or more). However, this seemed like a common expectation among existing Tridion Schema designers.

Would visualizing the minimum and maximum (min and max) constraints in the UI better represent this idea? Or is it about having the Allowed Multiple Items checkbox to better accurately reflect the Schema values?

Regardless of the visible setting for Multiple Values, does the Schema preserve its min and max settings for that field when changed?

Multiple values check box in schema when you change maxOccurs from "Unbounded"

When you tick the "Allow Multiple Values" option when building a schema field you get an Xml element in source like:

<xsd:element name="drawbacks" minOccurs="1" maxOccurs="unbounded" type="xsd:normalizedString" />

When you want to limit the number of these elements you can change maxOccurs to an integer, so to limit the number of these fields added by the user to 5 you would manually update source of the schema to:

<xsd:element name="drawbacks" minOccurs="1" maxOccurs="5" type="xsd:normalizedString" />

Sadly when you do this and go back to the Design view, the "Allow Multiple Values" option is unticked!

Minor, but annoying!

  • +1 for "constraints". Dealt with this exact issue today (and came here in fact to submit this as an idea). It would be ideal that `minOccurs` was separated from `Mandatory`;

    Alternatively, I'd be ok if `minOccurs` accepted a negative value, wherein a negative value meant "minimum items, but not required".

    I think ideally, what I'd like to see is a "constraint schema" that could be applied to individual fields. This would save the laborious task of making 10 or 15 schemas with a field that had to share the same constraints. And a constraints schema would allow us to apply custom messaging as well.

  • +1 for the schema addition of 'constraints' - this would, I hope, also include consideration for other constraints such as character qty, pattern patch etc.

  • I think making constraints accessible is ideal.

    No, if I change mandatory or translatable setting the schema loses its max settings and returns to maxOccurs="1" (as the allow multiple is unchecked).