Add spec for ObjectMessage encoding and decoding

[VeskeR]

This is the spec equivalent of the encoding/decoding logic implemented in ably-js for ObjectMessage

[sacOO7]

Suggested change

	*** @(OD4b1)@ A boolean payload is encoded as a MessagePack boolean type, and the result is set on the @ObjectData.boolean@ attribute.
	*** @(OD4b1)@ A boolean payload is encoded as a MessagePack boolean type, and the result is set on the @ObjectData.boolean@ attribute. The @ObjectData.encoding@ attribute is then set to "msgpack"

or you can add separate spec point for the same

[VeskeR]

The @ObjectData.encoding@ attribute is then set to "msgpack"

It must not be set in this case. Currently the ObjectData.encoding is only set when the payload is being JSON-stringified, in OD4b5 and OD4c5

[sacOO7]

Okay, then we should explicitly specify that it should not be set. Otherwise, it could easily be misinterpreted as to be set to either msgpack or json.
i.e. we set encoding field for OOP5a, OOP5b

[VeskeR]

Okay, then we should explicitly specify that it should not be set

I don't think it's reasonable to list all the things the client library should not do. ObjectData encoding/decoding spec should not be compared to encoding for ObjectOperation

[sacOO7]

Of course, it shouldn't be compared directly. However, from a reader's perspective, it's reasonable to expect that the encoding field would have a specific value. It's always better to define things explicitly in the spec to avoid any implicit misunderstandings. In this case, the spec doesn't clearly state whether a value should or shouldn't be set—it's rather ambiguous

[VeskeR]

that the encoding field would have a specific value

I do not agree with this. The spec is explicit in its phrasing that ObjectOperation.initialValueEncoding OOP3i must be set by the client library when sending create ops to the server, while the ObjectData.encoding OD2b may be set to indicate that one of the value fields has an additional encoding (an argument can be made that it shouldn't mention bytes field at the moment, as there is a no procedure for additionally encoding anything that goes into bytes).

[sacOO7]

I'm not currently comparing this with initialValueEncoding; rather, I'm trying to share my understanding from a reader's perspective. Specifically, this spec doesn't clearly state whether a value should or should not be set.

For example, in the case of OD4b5, it explicitly says to set the encoding to json. In other cases, we describe how the value is encoded—for instance, "A string payload is encoded as a MessagePack string type"—but we neither state that the encoding field must be set, nor that it should be left unset.

If we were to feed this spec into a context-driven LLM model, it would likely infer or assume some default value. That’s why I’m suggesting we make this aspect explicit in the spec to avoid ambiguity.

[VeskeR]

The current encoding spec for ObjectMessage was written in the same format as the encoding spec for regular messages in RSL4, where a spec only specifies when to set the encoding field.
That being said, I don't see a huge issue with adding a single spec point that states that encoding field is left unset by default, unless specified by the encoding procedure. Added it in https://github.com/ably/specification/compare/826e4bddf506d3923dc746edc893591ce78d245d..7f30177752945dae89891c9146109fbfa1dcea08

we describe how the value is encoded—for instance, "A string payload is encoded as a MessagePack string type"—but we neither state that the encoding field must be set, nor that it should be left unset.

I should note that ObjectData.encoding (just like Message.encoding from RSL4) is not meant to tell the client library that the value at the ObjectData.string attribute is string-encoded. It exists to inform the client library that the value represents something else and should be further processed. For example, if client received ObjectData.string with ObjectData.encoding set to json, then the string is actually a JSON string - so if you JSON-parse it, you'll get the original object.

[VeskeR]

ObjectData.encoding is no longer used and will be removed altogether in #360

[sacOO7]

Ideally ObjectData.encoding should be called ObjectData.isJsonString or ObjectData.isJson that is either set to true or false.
If it's true, we construct JsonObject or JsonArray from the @objectdata.string@ value.
Is it possible to be changed as a part of https://github.com/ably/specification/pull/335/files#r2144849490 changes
wdyt @lmars

[sacOO7]

ObjectData.encoding in itself feels misleading. When we apply msgpack encoding, ObjectData.encoding is set to either json or none

[lmars]

TBH if we make a change to the fields here, I'd suggest adding a separate json field which is explicitly used to send a JSON encoded value, rather than using the string field with encoding=json.

[sacOO7]

Okay, so field ObjectData.json set to true or false ?

[lmars]

No sorry, I mean ObjectData.json would be set to the JSON encoded value, for example ObjectData.json = '{"this":"is some json"}'), rather than what would currently be string = '{"this":"is some json"}', encoding = 'json'

[sacOO7]

Okay, understood, so new ObjectData will look like

class ObjectData // OD*, internal
  objectId: String? // OD2a
  boolean: Boolean? // OD2c
  bytes: Binary? // OD2d
  number: Number? // OD2e
  string: String? // OD2f
  json: String? // OD2g

This also makes logical sense—since the encoding field can be misleading. It implies that the encoding applies to the entire ObjectData( related discussion ), when in fact, it only refers to the encoding of a specific field.

[sacOO7]

@lmars, I guess this can be addressed as a part of getting rid of initialValueEncoding => #335 (comment)

[VeskeR]

spec for ObjectData.encoding and .json will be updated in #360

[sacOO7]

Btw, just noticed, both of my msgpack and json were using enum string to send and receive data. Instead it should use code starting from 0, can you add separate spec point for the same?

[lawrence-forooghian]

Instead it should use code starting from 0

Why?

[sacOO7]

Instead it should use code starting from 0

Why?

Apologies for the confusion — what I meant is that it should use the underlying code values. Currently, the enums have code values starting from 0, but in my case, the serializer was defaulting to serializing them as strings. Instead, it should encode the enum values using their underlying code representation.

[lawrence-forooghian]

Sorry, I don't think I know what you're referring to. What property are you talking about exactly, and what is the enum that you're referring to?

[lawrence-forooghian]

Sorry, I don't think I know what you're referring to. What property are you talking about exactly, and what is the enum that you're referring to?

Asked about this in standup — @sacOO7 just meant that the spec should be explicit that when sending an enum value (e.g. a MapSemantics) then the client should encode it as the numerical enum value. I don't think we need to do this here — we've been treating that as implicit elsewhere in the spec (e.g. when sending a PresenceAction or ProtocolMessageAction). Might not be good to be explicit about it in general but I don't think you need to let it distract you on this PR.