`subject.type` still declared in `schemas/ticketclosed.json` — incomplete removal from #262

[sol-duara]

Summary

schemas/ticketclosed.json is the only schema in the repository that still declares a subject-level type property. It appears to be a partial application of cdevents#262 ("chore!: remove subject.type", commit 72cee83), which resolved cdevents#189.

Observed on main at 00b986b (version.txt = 0.6.0-draft).

Evidence

• ticketclosed.json is the only file under schemas/ (and custom/) whose properties.subject.properties contains type. All other 48 event schemas were migrated.
• Its own siblings ticketcreated.json and ticketupdated.json do not declare it.
• spec.md documents subject attributes as REQUIRED id, content and OPTIONAL source — there is no subject-level type attribute in the specification text.
• The repository's own conformance fixture conformance/ticket_closed.json does not carry subject.type, so nothing in the conformance suite exercises the declared field.

Root cause

Commit 72cee83 made two edits per schema — removing the type property block from subject.properties, and removing "type" from subject.required. For ticketclosed.json only the second edit was applied.

schemas/ticketcreated.json (complete — both edits):

@@ -62,14 +62,6 @@
           "minLength": 1,
           "format": "uri-reference"
         },
-        "type": {
-          "type": "string",
-          "minLength": 1,
-          "enum": [
-            "ticket"
-          ],
-          "default": "ticket"
-        },
         "content": {
@@ -148,7 +140,6 @@
       "required": [
         "id",
-        "type",
         "content"
       ]

schemas/ticketclosed.json (incomplete — only the required edit):

@@ -166,7 +166,6 @@
       "required": [
         "id",
-        "type",
         "content"
       ]

Because the file was touched by the commit, it does not stand out when auditing which files the change reached.

Impact

properties.subject.additionalProperties is false on all three ticket schemas. The result is that a producer may send subject.type on dev.cdevents.ticket.closed.0.2.0, but the same field is rejected on dev.cdevents.ticket.created.0.2.0 and dev.cdevents.ticket.updated.0.2.0.

So a single subject validates inconsistently across its own lifecycle, and consumers written against ticket.closed may treat a subject-level discriminator as available when the specification does not define one. Since subject.type carries "default": "ticket", schema-driven code generators and form/documentation tooling may also emit the field for this one event type.

Suggested fix

Delete the residual block at schemas/ticketclosed.json lines 65–72:

         "source": {
           "type": "string",
           "minLength": 1,
           "format": "uri-reference"
         },
-        "type": {
-          "type": "string",
-          "minLength": 1,
-          "enum": [
-            "ticket"
-          ],
-          "default": "ticket"
-        },
         "content": {

subject.required is already correct (["id", "content"]), and conformance/ticket_closed.json already omits the field, so no fixture change is needed.

Happy to open a PR if that's useful.

Notes

Since subject.type was removed as a breaking change in v0.5.0, removing this last declaration is a no-op for any producer already conforming to the documented specification. It does technically narrow what ticket.closed accepts, so it may warrant a line in the 0.6.0 release notes alongside the original cdevents#262 entry.