If you take advantage of the inline Schema (xsd) constraints in SDL Tridion Sites 9.5's Experience Space UI, you might need an example. 

SDL Tridion Sites has long had the ability to constrain the values that editors can enter into the content management system.

As an example, you might choose to constraint the specific characters allowed in a text field, the minimum and maximum entries for a field, or otherwise control the range of valid entries.

The SDL Documentation Center explains how the following facets apply to various field types:

• Minimum and maximum length of fields
• Pattern (regular express) match
• Minimum to maximum number values or dates (inclusive or exclusive)
• Total digits and number of decimal (fraction) digits   

See a classic example from Nuno Linhares that makes a field that requires a first capitalized letter. The customization and follow-up post aren't needed if using Experience Space.

Note that such (xsd) constraints appear inline in in Experience Manager. They are enforced when saving in the soon-to-be Classic UI. And as mentioned, they will now apply inline in the Experience Space user interface being introduced in SDL Tridion Sites 9.5.

Here's an example from the Source of a Schema for a text field that forces an initial capitalized letter.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.com/article" xmlns:tcmi="http://www.tridion.com/ContentManager/5.0/Instance" elementFormDefault="qualified" targetNamespace="http://example.com/article">
  <xsd:import namespace="http://www.tridion.com/ContentManager/5.0/Instance"></xsd:import>
    <xsd:annotation>
      <xsd:appinfo>
        <tcm:Labels xmlns:tcm="http://www.tridion.com/ContentManager/5.0">
          <tcm:Label ElementName="Heading" Metadata="false">Heading (must start with capital letter, allowing letters and numbers)</tcm:Label>
        </tcm:Labels>
      </xsd:appinfo>
      </xsd:annotation>
    <xsd:element name="Content">
  <xsd:complexType>
<xsd:sequence>
<xsd:element name="Heading" minOccurs="0" maxOccurs="1">
  <xsd:annotation>
    <xsd:appinfo>
      <!-- Sites 9.5 only -->
      <tcm:IsPublishable xmlns:tcm="http://www.tridion.com/ContentManager/5.0">true</tcm:IsPublishable>
      <tcm:IsIndexable xmlns:tcm="http://www.tridion.com/ContentManager/5.0">true</tcm:IsIndexable>

      <tcm:ExtensionXml xmlns:tcm="http://www.tridion.com/ContentManager/5.0"></tcm:ExtensionXml>
    </xsd:appinfo>
   </xsd:annotation>
   <xsd:simpleType>
     <xsd:restriction base="xsd:normalizedString">
       <xsd:pattern value="[A-Z][A-Za-z0-9_ ]*"></xsd:pattern>
          </xsd:restriction>
   </xsd:simpleType>
   </xsd:element>
   </xsd:sequence>
   </xsd:complexType>
  </xsd:element>
</xsd:schema>

Note specifically the lack of a type on the element node. Also the IsPublishable and IsIndexable nodes only apply for SDL Tridion Sites 9.5, which are controlled in the Schema form editor and support data pipeline publishing.

In terms of applying such limits in a multi-channel or multi-lingual scenario, I recommend:

• Be aware of the desired constraints across all languages, lengths of texts, and output formats. It doesn't make sense to constraint something that could drastically vary across languages.
• Similarly, minimum and maximum numbers of values could be useful, though make sure something like "maximum" is more related to an actual limit and not a specific channel. For example, a website might have spots for 3 pieces of related content today. But is that the same for all channels and responsive break points? Might it change?
• Keep in mind the editor's flow. The more you constrain and force things like mandatory values (especially when not really mandatory or used), the more likely editors might opt for shortcuts and pasted text.

With these recommendations in mind, I think content manager-side field validation is a good candidate for:

• Specific, non-changing, and standardized data formats like GUIDs or other known IDs
• Constraining limits when the output format is known and has a hard limit (e.g. display on digital signage with limited characters)
• Standardizing simpler fields, especially when used for fewer languages or represent some internal, non-published information 

I hope you like the feature and use it where needed. In the future we'll revisit the Schema form editor and perhaps adjust the inline field validation based on your feedback. Keep the idea submissions coming and feel free to share good and bad stories of content entry field validation, for this or any product you've worked with!

Update (2024-06-03): fixed description of the regular expression scenario.