We would need to define what the "Object Representation" is, and really, it's not a representation of the Internal Representation, it is the Internal Representation.

The first two substitutions are actually the JSON representation, so those should remain unchanged.

@gkellogg what about this?

• "Object Representation" removed;
• Notes about JSON-LD API functions converting their output from JSON Serialization removed.

Might close: #605

Added two subsections trying to explain these things. @gkellogg what do you think?

We'll need a normative statement (in an appropriately normative section) that a processor MUST serialize the internal representation to JSON when responding to a content negotiated request for application/json or a sub-type (such as application/ld+json). YAMl-LD would need a similar statement, as would CBOR-LD. The section 9.1.2 Serialization and Deserialization is informative sets the stage for other format serialization requirements.

@gkellogg

processor MUST serialize the internal representation to JSON when responding to a content negotiated request for application/json or a sub-type (such as application/ld+json)

I see but... I think processor does not handle content negotiation at all, does it? That's what the user application can be doing. Or not. For instance, I write a console program which reads and writes JSON-LD and YAML-LD; it has nothing to do with content negotiation. But it serializes data in either format based on what --format value I submit to it when calling.

@gkellogg

processor MUST serialize the internal representation to JSON when responding to a content negotiated request for application/json or a sub-type (such as application/ld+json)

I see but... I think processor does not handle content negotiation at all, does it? That's what the user application can be doing. Or not. For instance, I write a console program which reads and writes JSON-LD and YAML-LD; it has nothing to do with content negotiation. But it serializes data in either format based on what --format value I submit to it when calling.

There are plenty of normative requirements about using HTTP headers, such as Accept, Link and Profile. A JSON-LD processor MUST return a suitable serialization based on the Accept header (content negotiation). If the header indicates application/yaml or a sub-class, that would be YAML, if application/json or a sub-class, that would be JSON. We previously (erroneously) did this in the API method descriptions. The idea is to make the wording more generic and make the serialization requirement not directly tied to the detailed descriptions of the API methods.

@gkellogg maybe you could please direct me to tests covering this behavior?

You want the Remote Document Test Manifest.

@gkellogg I believe the deserialization procedure is handled by LoadDocumentCallback, adding a reference to it at the Serialization and Deserialization section. I am not sure how to go about the serialization though. Perhaps let's discuss this on the nearest meeting.

This was discussed during the json-ld meeting on 13 November 2024.

@anatoly-scherbakov when you have several suggestions to commit, try using the batch commit feature from the Files menu; it creates only one commit which includes all the suggestions you add.

Thanks!

I don't think I can merge:

You're not authorized to push to this branch. Visit https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches for more information.

@gkellogg I am open to doing it. Perhaps you could suggest where to look for an example, maybe another, already merged, PR formulated in this way?

I will open further PRs in the main repo rather than my fork.

@gkellogg I am open to doing it. Perhaps you could suggest where to look for an example, maybe another, already merged, PR formulated in this way?

Check out #616 for how it is done. Basically, a div with class "candidate correction" and an id of "change_5" (or whatever is the next correction in sequence) such as is found here

And ins del with citations to the correction such as

Also, an entry in the Changes since Rec referencing the issue and the candidate correction div.

It's more complicated when there are changes in multiple places. There, you might have links to each correction ins/del from the candidate correction block.