The full /api/v2/items response must validate against the published catalogue XML Schema.

What this check does: Fetches GET /api/v2/items once, then validates the returned XML against the compiled catalogue schema (qc-catalogue-api-schema.xsd, which imports qc.xsd). Emits one finding per schema error (its message and line); passes when the document is schema-valid.

Each single-item response (/api/v2/items/{id}) must validate against the catalogue XML Schema.

What this check does: Lists the published item ids (each the latest published version) and fetches GET /api/v2/items/{id} for every one, validating each against the same compiled schema. One finding per schema error; the total number of items checked is reported.

Enum-typed and value elements (Representation, Type, ValueRange, Unit, DefaultValue) must not be emitted empty. The XSD cannot enforce this (the enum value lists are not in the schema), so the API must omit an element rather than send it empty. On the v2 target elements explicitly marked xsi:nil are allowed; on the v3 target they are not (no v3 element is nillable, #1981).

What this check does: Parses GET /api/v2/items or /api/v3/items (whichever this run targets) and walks every ItemInfo; flags any Representation/Type/ValueRange/Unit/DefaultValue leaf that is present but has no text and no children and is not marked xsi:nil. On v3 an xsi:nil one is flagged too. Note this check thus covers all latest versions of the QC Items.

API responses must carry the documented Content-Type: application/xml with a charset parameter (catalogue-API spec section 3.4).

What this check does: Reads the Content-Type response header of GET /api/v2/items and checks the media type is 'application/xml' and a 'charset' parameter is present (media type and parameters matched case-insensitively per RFC 7231). One finding per problem. In deployed environments the list endpoint is fetched over a real HTTPS request through nginx, so the header seen is the one an external client receives.

Warns if any tracked API response header changed since the previous scan, so header changes are noticed even when the new value still complies with the documented policy.

What this check does: Snapshots a curated set of response headers from GET /api/v2/items and compares them to the snapshot stored by the previous run; warns on any difference. The first run only records the baseline and passes. In deployed environments the endpoint is fetched over a real HTTPS request through nginx, so the snapshot includes the edge-set security headers (HSTS, X-Content-Type-Options, Referrer-Policy) an in-process read cannot see; switching source re-baselines rather than false-alarming.

The XML namespace URIs emitted by the API should match those declared in the published XSD; a mismatch forces clients to remap namespaces before validating.

What this check does: Reads the root element's namespace map from GET /api/v2/items and compares the emitted qc and qcc namespace URIs to the targetNamespace declared in the shipped XSDs; one finding per prefix that differs.

The server's {apiVersion} path segment shall equal 'v3' for this version of the specification. Verify the request URL contains '/v3/'. (Checked at the HTTP layer.) (spec 3.2, p.2)

What this check does: Checks that the list and single-item paths the validator calls carry this validator's apiVersion segment, and that the list endpoint answers HTTP 200 there.

A 200 response to GET {base}/items shall be a single XML document with an <Items> element as its root. (spec 4.1.4.1, p.5)

What this check does: Calls /api/v2/items and checks the root element is <Items>.

Each /Items/ItemInfo corresponds to the latest published version of an item, and Items includes all items of the catalogue; so an EBUQCID must not appear in more than one ItemInfo. (spec 4.1.4.1, p.5)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

A 200 response to GET .../items/{id} or .../items/{id}/versions/{version} shall be a single XML document with an <ItemInfo> element as its root. (spec 4.2.4.1 / 4.3.4.1, p.6)

What this check does: Runs the rule's element scan over each sampled single-item response (up to 40).

The server should serve endpoints over TLS 1.2+ and request URLs should therefore use https. This is a 'should' requirement in catalogue-API spec 3.1, so a failure is reported as a warning, not a hard failure.

What this check does: Opens a real outbound TLS connection to the configured HOST_URL (TLS 1.2 floor, certificate verified) and passes only if the handshake succeeds; a non-https URL or a failed handshake warns.

GetItems should implement the entity-tag feature (RFC 7232) so clients can poll efficiently, and responses should carry an ETag header. This is a 'should' requirement in catalogue-API spec 4.1.1, so a missing ETag is reported as a warning, not a hard failure.

What this check does: Fetches GET /api/v2/items and checks the response carries an ETag header. The listing view attaches a content-based ETag and answers conditional GET (If-None-Match) with 304. In deployed environments this is a real HTTPS request through nginx, so a strong ETag dropped or weakened at the edge is caught too.

Each QC Item Definition must appear exactly once in the /items response - a duplicate EBUQCID means the same item is listed more than once. (Item names/EBUQCName need not be unique.)

What this check does: Parses GET /api/v2/items, counts each EBUQCID across all ItemInfo entries, and flags any EBUQCID that occurs more than once. EBUQCName is not checked (the data model does not require distinct names).

For every entry, ThisVersion must equal the highest version listed under Versions.

What this check does: For each ItemInfo in GET /api/v2/items, parses ThisVersion and the Versions/Version values as numeric major.minor.patch tuples and flags any item whose ThisVersion is not the maximum listed.

Value-related fields must follow the model: an Output must not carry a DefaultValue (both targets); on the v2 target only, a Group (a parameter with nested Input/Output children) must carry no value fields (Type, ValueRange, Unit, Representation, DefaultValue, Aliases) of its own -- v3's real schema (#1750) has no Group element at all, so that sub-check does not apply there (and xsd-items/xsd-item already reject one if it ever appeared). Instead, on v3 an Input/Output without a Type must carry none of those value fields (Annex C.4, #1981).

What this check does: Walks GET /api/v2/items or /api/v3/items (whichever this run targets); flags any Output that contains a DefaultValue, and, on the v2 target, any Group whose direct children include Type, ValueRange, Unit, Representation, DefaultValue or Aliases; on the v3 target, any Input/Output with no Type child whose direct children include one of the others.

CheckResultDefinition must be present/absent as the model requires. On the v2 target the element must never appear (v2's schema has no such element; its appearance signals drift). On the v3 target (#1750) the element is optional in the XSD but mandatory in practice on any item usable as a check -- mirroring items.models.Value's own #1724 rule -- so every check-usable item must carry a non-empty value.

What this check does: v2: walks GET /api/v2/items and flags any element named CheckResultDefinition (with the containing item id) -- the v2 API never emits this element, so this only catches drift. v3: walks GET /api/v3/items and flags any item whose UsableAs includes 'check' but whose CheckResultDefinition is missing or blank.

General model compliance for each QCItemDefinition: a well-formed EBUQCID ([0-9]{4}[A-Z]{1,2}), a non-empty EBUQCName, and a Status restricted to the publicly exposed states (published/withdrawn). Extend this check as more model rules are codified.

What this check does: For each ItemInfo in GET /api/v2/items, checks the EBUQCID against ^[0-9]{4}[A-Z]{1,2}$, that EBUQCName is non-empty, and that Status is one of the published/withdrawn display labels; one finding per violation.

ItemInfo/ThisVersion holds the EBUQCVersion of a published version of the item and must match EBUQCVersionType (MAJOR.MINOR[.PATCH]). (spec 3.7.2.2, p.3)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

ItemInfo/Versions lists all published versions; the value of ThisVersion must be one of the listed Version values. (spec 3.7.2.3, p.4)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

ItemInfo/Item contains the version of the item identified by ThisVersion, so Item/EBUQCVersion must equal ThisVersion. (spec 3.7.2.5, p.5)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

Card/Language specifies the language of the card's text lines and must be a valid xs:language tag. (spec 3.7.2.4, p.4)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

For Icon and FullImage, each Source/Location is an absolute URI and the image resource conforms to the W3C PNG specification. The API's own routed image endpoints (.../image/{icon,card}/{size}/) redirect to a re-encoded PNG, so they are recognised as PNG rather than flagged for their extensionless URL; only a non-routed Location is judged by its extension. (spec 3.7.2.4, p.5)

What this check does: Scans each Icon/FullImage Source/Location on the /api/v2/items listing: flags a non-absolute URI, and for the PNG requirement recognises the API's routed image endpoints (.../image/{icon,card}/{size}/), which always redirect to a re-encoded PNG, as conforming without fetching them; only a non-routed Location is judged by its .png extension.

ImageSourcesType requires one or more <Source> children (each with Width, Height and Location). (spec 3.7.2.4, p.5)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

{id} and every EBUQCID conform to EBUQCIDType: one or more characters from [0-9a-zA-Z-]. (spec 3.6.1, p.3)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

{version} and every EBUQCVersion conform to EBUQCVersionType (MAJOR.MINOR[.PATCH]). (spec 3.6.2, p.3)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

AnalysisMethod (AnalysisMethodType), when present, may only be 'readout', 'measurement' or 'readout and measurement'. (spec Annex A, p.22)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

Layer (LayerType) may only be 'wrapper', 'bitstream', 'baseband' or 'crosscheck'. (spec Annex A / B.1, p.22)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

EssenceType may only be 'video', 'audio', 'text-data' or 'format'. (spec Annex A, p.22)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

Category (CategoryType) may only be 'regulatory', 'absolute', 'objective', 'subjective' or 'human-only review'. (spec Annex A / B.2, p.22)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

Status (PublicationStatusType) is under revision; the legacy 'active' value maps to 'published'. The API exposes only 'published' and 'withdrawn' item versions, so any Status other than 'published' or 'withdrawn' is flagged for review. (spec Annex A, p.22)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

DatatypeType, RangeType, UnitType and RepresentationType are controlled lists maintained outside the schema at https://qc.ebu.io/parameters/{type,range,unit,representation}; values must be validated against those lists. (spec Annex A, p.22)

What this check does: Documented for reference only: this rule performs no automated assertion in the validator and always passes. It is enforced at the HTTP layer, or fully verifying it needs data the catalogue API does not expose.

The QC XML Schema never uses element attributes; any attribute (other than xsi:*) is unexpected. (spec 1.2 (note), p.1)

What this check does: Runs the rule's element scan over the /api/v2/items listing (every ItemInfo entry).

Every emitted controlled-vocabulary value (Representation, Type, Unit, ValueRange) must be a defined vocabulary entry. The XSD cannot enforce this because the value lists are not in the schema (data-model Annex A marks them as externally maintained controlled lists). Empty elements are reported separately by the no-empty-elements check, so this check only validates non-empty values.

What this check does: Loads the allowed Representation/Type/Unit/ValueRange values from the parameters database, then walks GET /api/v2/items and flags any such element whose non-empty text is not in the corresponding allowed set (empty and xsi:nil elements are skipped).

The API exposes only items published at least once, and only their published/withdrawn versions. Anything else returns an empty-body 404. This verifies a published item returns 200, and that a never-published item and a non-existent id both return a bare 404.

What this check does: Fetches one published item and asserts 200; fetches a syntactically valid but non-existent id (9999ZZ) and a never-published draft id, asserting each returns 404 with an empty body. One finding per deviation.