Terminology for processing modes

[filip26]

There are two processing modes mentioned in this spec: General Processing and Type-Specific Processing. A single note in the DI spec points to this section. Other related specs provide only brief descriptions of processing modes, and when they mention them, they typically refer to them as JSON-LD processing vs. JSON processing.

This lack of proper terminology to clearly denote the underlying processing concepts makes those specs open to interpretation. Relying on JSON-LD vs. JSON is not an ideal solution, as it defines the processing at the serialization level rather than at the conceptual level. Terms like General Processing and Type-Specific Processing are not sufficiently descriptive and may be difficult to interpret.

Would Semantic vs. Lexical be a better terminology? This would allow us to define two dedicated sections for each processing mode and apply consistent terminology across the specifications.

This issue is being raised to spark a discussion. Feel free to close it if there is already consensus on the current terminology.

[iherman]

This was discussed during the vcwg meeting on 15 July 2026.

View the transcript

w3c/vc-data-model#1634

brent: This one we're looking at because it's un-triaged. Terminology
… Two processing modes are mentioned. We're not proposing a re-opening of that conversation. This is asking rather than framing in terms of JSON vs JSON-LD should we use different terminology

brent: IMo this could be addressed as a editorial change. What do others think?

<dlongley> +1 sounds editorial

brent: If no objection, I'll add a class 2 label

brent: If there's anything folks want to say, please jump on the queue

brent: Should we rename? Makes sense to me

dlongley: I think the spec currently calls it general vs type-specific. We no longer call it JSON vs JSON-LD. SO is there a better name than the spec currently has? I do think it's editorial

phila: You and I talked about this. We are looking for an editor for the VCDM spec.

phila: We are looking at who has been and has been active and we could use another name. We could use another name for political reasons so we have another person working for another company on that spec. We need you, thanks!

brent: TO be clear, there is an ask for additional editorial support for VCDM 2.1
… You can do it by telling the chairs, or you can just start writing PRs

<dmitriz> I'd volunteer, but I'm Invited Expert, and I suspect a member company person is needed for editor

---

[dmitrizagidulin]

@filip26 Thanks for bringing this up, these are good points.

Regarding "semantic vs lexical": I can see why that's tempting, but it's important for the spec to emphasize that both modes yield the same semantics. (Plus we don't want to resurrect the "json vs json-ld" argument.)

If anything the difference is more about -- whether a @context is process dynamically (resolved via json-ld algos) vs statically (a fixed, vetted set of context values engineered in ahead of time).

Concrete proposals:

1. We add a short "Processing Modes" section under Syntaxes, with an opening <dfn> tag, so that the DI spec and VC-JOSE-COSE can have something concrete to point to.
2. Rewrite both definitions conceptually. Meaning, we define each mode by which @context values an implementation accepts and how term-to-URI meaning is established (general processing "accepts previously unseen context values and establishes term meaning dynamically by applying JSON-LD algorithms", and type-specific processing "accepts only specific, pre-vetted context values whose term meanings are engineered into the implementation ahead of time.")
3. Normalize the terminology without the spec (because it's drifting, the text variously says "generalized JSON-LD processing" (line 4343), "generalized processors" (4584, 4600), and "generalized processing" (4612)). We can just replace them with [=...=] links to the dfn sections.
4. Emphasize that the modes are equivalent. We add a sentence saying the two modes differ in how context is processed as opposed to the resulting interpretation, and a conforming document means the same thing under either mode.

I'm happy to do that if the group agrees.

[filip26]

@dmitrizagidulin Thanks, and +1 to the proposals.

Regarding terminology, it would be great to reflect that even the processing result is equivalent when rules, e.g. an unknown context rejection, are met (though I am not sure if this is consolidated in one place). The core difference is that one mode relies on JCS ("lexically checked" JSON) and the other on RDFC (JSON-LD transformed into RDF). Not saying "lexical/semantic" is ideal, it was just an idea reflecting the c14n approach.

[iherman]

• Rewrite both definitions conceptually. Meaning, we define each mode by which @context values an implementation accepts and how term-to-URI meaning is established (general processing "accepts previously unseen context values and establishes term meaning dynamically by applying JSON-LD algorithms", and type-specific processing "accepts only specific, pre-vetted context values whose term meanings are engineered into the implementation ahead of time.")

I am a bit worried elevating an implementation choice into a concept. If we talk conceptually, a JSON-LD application follows the underlying JSON-LD processing model, and the @context handling aspect in the spec does not say where the "active context", as it is called, comes from. Whether it is retrieved from the Web every time, cashed, or "engineered into the implementation" is a choice that we should not use to differentiate on the VCDM specification level imho.