One of the endless struggles in writing reusable API endpoints is creating useful schemas to describe them. Each new serialization format comes up with new ways to express your constraints, each with their own quirks and footguns and absolute trainwrecks.
Maarten has the “pleasure” of consuming an XML-based API, provided by a third party. It comes with an XML schema, for validation. Now, the XML Schema Language has a large number of validators built in. For example, if you want to restrict a field to being a date, you can mark it’s type as xsd:date. This will enforce a YYYY-MM-DD format on the data.
If you want to ruin that validation, you can do what the vendor did:
<xsd:simpleType name="DatumType">
<xsd:annotation>
<xsd:documentation>YYYY-MM-DD</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:date">
<xsd:pattern value="(1|2)[0-9]{3}-(0|1)[0-9]-[0-3][0-9]" />
</xsd:restriction>
</xsd:simpleType>
You can see the xsd:pattern element, which applies a regular expression to validation. And this regex will “validate” dates, excluding things which are definitely not dates, and allowing very valid dates, like February 31st, November 39th, and the 5th of Bureaucracy (the 18th month of the year), as 2025-02-31, 2025-11-39 and 2025-18-05 are all valid strings according to the regex.
Now, an astute reader will note that this is a xsd:restriction on a date; this means that it’s applied in addition to ensuring the value is a valid date. So this idiocy is harmless. If you removed the xsd:pattern element, the behavior would remain unchanged.
That leads us to a series of possible conclusions: either they don’t understand how XML schema restrictions work, or they don’t understand how dates work. As to which one applies, well, I’d say 1/3 chance they don’t understand XML, 1/3 chance they don’t understand dates, and a 1/3 chance they don’t understand both.
Source: Read MoreÂ