XSD guide
How the XSD pattern facet really matches
Write XSD regular-expression facets without assuming anchors or host-language features, account for normalization, and test boundary literals.
8 min read · Updated 2026-08-21
The short answer
XSD pattern uses the XML Schema regular-expression language, not JavaScript, PCRE, or Java syntax. Matching is not implicitly anchored, and ^ or $ are not those engines' anchors. Combine the pattern with length or other facets when the whole lexical form matters, then test boundary values with the actual validator.Use the XSD regex language
Familiar metacharacters overlap with other regex engines, but feature sets and escaping differ. Do not paste lookarounds, backreferences, inline flags, or host-language string escapes into a schema and assume equivalent behavior.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="ProductCode">
<xs:restriction base="xs:string">
<xs:length value="7"/>
<xs:pattern value="[A-Z]{3}[0-9]{4}"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>Account for unanchored matching and normalization
A pattern can match a substring, so a seven-character length facet in the example prevents extra characters around the product code. Facets also apply after the base datatype's whitespace behavior: token-derived types collapse whitespace while xs:string preserves it.
- Choose the base datatype before designing the pattern.
- Test leading, trailing, repeated, and non-breaking whitespace.
- Test extra characters before and after the intended core.
- Use length or enumeration facets when they express the rule more directly.
Build a boundary table beside the schema
For every pattern, keep representative valid values and near misses: wrong case, one character short, one extra character, unexpected Unicode, and whitespace variants. Execute that table with the same XSD version and validator used in production.
When a pattern becomes difficult to explain, split the contract across datatype, length, enumeration, and pattern facets instead of encoding every business rule in one expression.
Prove the fix
- Validate boundary literalsRun accepted values and near misses through the production validator.
- Inspect the pattern facetCompare XSD regex behavior with common host-language assumptions.
- Read the facet errorMatch the documented libxml2 message to a failing value.
Related guides
- How to validate XML against an XSDSeparate parsing from schema validation, load the complete schema set, and reduce validation errors to the smallest failing instance.
- How to fix “Element is not expected” in XSDUse the expected-element list to find namespace, order, or occurrence mistakes instead of deleting the child the validator names.
Get started
Bring order to the XML your team can't afford to ignore.
Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.