Issue found during schema testing: two fields in a schema had a : character in the field key. Guardian accepted the schema on import/save, but the : is a reserved JSON-LD character (used for prefix:term compaction), and it produced a JSON-LD validation error downstream. Had to manually rename the two fields to unblock testing.
Ask:
- Validation — Guardian should flag/reject
: in a schema field key at authoring/import time (Excel and in-app schema editor), with a clear error message pointing to the offending field, rather than letting it pass silently and fail later at JSON-LD validation.
- Docs — Add a note to schema authoring documentation about reserved/disallowed characters in field keys (starting with
:).
- Excel template README tab — Add the same reserved-character guidance to the README/Guidance tab generated with Excel schema templates, so authors see it at the point of authoring.
Why now: related to the existing "Lack of documented validation rules when uploading schemas via Excel" work (GRD-73, done) — this is a specific validation gap that slipped through that effort.
Issue found during schema testing: two fields in a schema had a
:character in the field key. Guardian accepted the schema on import/save, but the:is a reserved JSON-LD character (used for prefix:term compaction), and it produced a JSON-LD validation error downstream. Had to manually rename the two fields to unblock testing.Ask:
:in a schema field key at authoring/import time (Excel and in-app schema editor), with a clear error message pointing to the offending field, rather than letting it pass silently and fail later at JSON-LD validation.:).Why now: related to the existing "Lack of documented validation rules when uploading schemas via Excel" work (GRD-73, done) — this is a specific validation gap that slipped through that effort.