The element’s value fails a pattern restriction on its simple type. XML Schema regular expressions describe an accepted lexical shape; they are not a general-purpose JavaScript or Java regex configuration. Inspect the actual xs:pattern before changing application regex code.
What the message literally means
The SKU type in this example requires two uppercase letters, a hyphen and three digits. ab204 lacks both the required letter case and separator. BK-204 satisfies the declared pattern, so the corrected XML passes with the same XSD. Xerces also emits the broader cvc-type.3.1.3 message for the enclosing value.
Three common causes to check first
The value has the wrong case, separators or character class. Visually similar Unicode punctuation can differ from the literal characters permitted by the pattern.
A regex from another language was copied into the schema. Escapes, character classes and unsupported constructs must follow XSD regex rules rather than a browser regex tester.
Whitespace processing changes what reaches the pattern check. A string-derived type and a token-derived type can treat surrounding or repeated whitespace differently.
Repair and retest
Open the type restriction and read the pattern together with its base type and any inherited restrictions. Compare a known passing value with the failing text character by character. Reproduce the check in an XSD validator, then make the smallest contract-preserving correction. Test nearby values such as lowercase letters or a missing digit so the producer’s normalization does not accept an unintended SKU shape.
When this is a namespace problem
A pattern failure normally means a declaration was found and its value restriction ran. A namespace mistake becomes relevant if the wrong element or xsi:type caused an unexpected restriction to be selected. First confirm which simple type supplied the reported pattern; changing xmlns will not uppercase letters or insert a hyphen.
Reading equivalent reports
Do not “fix” this by deleting xs:pattern or replacing it with a catch-all expression. The pattern may encode a receiver’s identifier format. If the receiver’s documented SKU format has changed, update the contract through its normal version process and test both old and new producers against that version.
Complete tested XML and XSD pairs
Open either variant in the workbench, then choose Validate XML. Loading an example does not run validation or send documents; server checks require the existing permission checkbox.
cvc-pattern-valid: Value 'ab204' is not facet-valid with respect to pattern '[A-Z]{2}-[0-9]{3}' for type '#AnonType_sku'.
cvc-type.3.1.3: The value 'ab204' of element 'sku' is not valid.
PASS
.NET 8.0.33 · System.Xml.Schema Validation
The 'sku' element is invalid - The value 'ab204' is invalid according to its datatype 'String' - The Pattern constraint failed.
PASS (no warnings)
XSDHub libxml2/WASM 0.7.2 Validation
Element 'sku': [facet 'pattern'] The value 'ab204' is not accepted by the pattern '[A-Z]{2}-[0-9]{3}'.
PASS
XSDHub xmlschema 4.3.1 · XSD 1.0 Validation
value doesn't match any pattern of ['[A-Z]{2}-[0-9]{3}']
PASS
Saxon
EE comparison: cvc-pattern-valid describes the corresponding XSD constraint. No Saxon-EE run or wording is claimed; an EE licence is unavailable in this test environment. Saxon-HE does not provide XSD validation.
The corrected results apply to these self-contained XSD 1.0 specimens. They do not establish business-rule acceptance for a different document or schema version.