| title | description | author | ms.author | ms.reviewer | ms.date | ms.service | ms.subservice | ms.topic | helpviewer_keywords | ||
|---|---|---|---|---|---|---|---|---|---|---|---|
Canonical Forms and Pattern Restrictions |
Learn how to prevent issues that occur when the canonical representation of primitive value types doesn't comply with pattern restrictions from an XSD pattern facet. |
MikeRayMSFT |
mikeray |
randolphwest |
05/05/2022 |
sql |
xml |
conceptual |
|
[!INCLUDE SQL Server Azure SQL Database Azure SQL Managed Instance]
The XSD pattern facet allows for the restriction of the lexical space of simple types. When a pattern restriction is put on a type for which there's more than one possible lexical representation, some values could cause unexpected behavior upon validation.
This behavior occurs because lexical representations of these values aren't stored in the database. Therefore, the values are converted to their canonical representations when serialized as output. If a document contains a value whose canonical form doesn't comply with the pattern restriction for its type, the document is rejected if a user tries to reinsert it.
To prevent this, [!INCLUDEssNoVersion] rejects any XML document that contains values that can't be reinserted, because of the violation of pattern restrictions by their canonical forms. For example, the value "33.000" doesn't validate against a type derived from xs:decimal with a pattern restriction of "33\.0+". Although "33.000" complies with this pattern, the canonical form, "33", doesn't.
Therefore, you should be careful when you apply pattern facets to types derived from the following primitive types: boolean, decimal, float, double, dateTime, time, date, hexBinary, and base64Binary. [!INCLUDEssNoVersion] issues a warning when you add any such components to a schema collection.
Imprecise serialization of floating-point values has a similar problem. Because of the floating-point serialization algorithm used by [!INCLUDEssNoVersion], it's possible for similar values to share the same canonical form. When a floating-point value is serialized and then reinserted, its value may change slightly. In rare cases, this may result in a value that violates any of the following facets for its type on reinsertion: enumeration, minInclusive, minExclusive, maxInclusive, or maxExclusive. To prevent this, [!INCLUDEssNoVersion] rejects any values of types derived from xs:float or xs:double that can't be serialized and reinserted.