An open-data feed validator rejects a published JSON document after a manual edit. The file is otherwise complete but includes a trailing comma in an object. What is the problem?

An open-data feed validator that rejects a published JSON document containing a trailing comma in an object is dealing with invalid JSON syntax that blocks parsing. Strict JSON (as used by RFC 8259 parsers) does not allow trailing commas after the last property in an object or the last element in an array. A manual edit that leaves that comma makes the document illegal; the municipal feed validator correctly refuses to accept it even if the rest of the content looks complete. The fix is to remove the trailing comma and re-validate before publish.

Calling the file valid JSON the validator must accept fails by concept: trailing commas are precisely what make many “almost JSON” documents invalid. Citing a successful 2xx API status as proof of well-formedness fails because transport success does not redefine JSON grammar; an API might store opaque bytes elsewhere, but a feed validator’s job is syntactic correctness. Requiring an INI section header inside every JSON file fails because INI and JSON are different configuration/syntax families; open-data JSON feeds are not validated against INI section rules.

Exam caveat: some languages’ JSON5 or lenient parsers allow trailing commas—exam and production municipal validators usually mean strict JSON. Do not assume that “the file opens in a text editor” equals “the file is valid JSON.”

Operational check: run the document through a strict JSON parser in CI before publish, reject trailing commas and other syntax defects, show editors a clear line/column error, and only then promote the open-data feed so downstream civic apps do not break on parse.