Confusing interaction between additionalProperties and optional fields.

Comience con el esquema ClientCapabilities en schema/2024-11-05/schema.json#L144 y el tipo Rust generado que se muestra en el issue. Siga cómo se asignan additionalProperties y los campos required ausentes durante la generación de tipos y, después, compare ese comportamiento con TypeSpaceSettings::with_map_type. Se considerará terminado cuando el proyecto tenga un comportamiento decidido y probado para conservar o colapsar intencionadamente la semántica de presencia de sampling y experimental.

given this schema:
https://github.com/modelcontextprotocol/specification/blob/main/schema/2024-11-05/schema.json#L144

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "definitions": {
"ClientCapabilities": {
            "description": "Capabilities a client may support. Known capabilities are defined here, in this schema, but this is not a closed set: any client can define its own, additional capabilities.",
            "properties": {
                "experimental": {
                    "additionalProperties": {
                        "additionalProperties": true,
                        "properties": {},
                        "type": "object"
                    },
                    "description": "Experimental, non-standard capabilities that the client supports.",
                    "type": "object"
                },
                "roots": {
                    "description": "Present if the client supports listing roots.",
                    "properties": {
                        "listChanged": {
                            "description": "Whether the client supports notifications for changes to the roots list.",
                            "type": "boolean"
                        }
                    },
                    "type": "object"
                },
                "sampling": {
                    "additionalProperties": true,
                    "description": "Present if the client supports sampling from an LLM.",
                    "properties": {},
                    "type": "object"
                }
            },
            "type": "object"
        }
}
}

My understanding (I could be incorrect) is that all three properties should be optional, as none are specified as required. However, typify produces

pub struct ClientCapabilities {
    #[doc = "Experimental, non-standard capabilities that the client supports."]
    #[serde(default, skip_serializing_if = "std::collections::HashMap::is_empty")]
    pub experimental: std::collections::HashMap<String, serde_json::Map<String, serde_json::Value>>,
    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub roots: Option<ClientCapabilitiesRoots>,
    #[doc = "Present if the client supports sampling from an LLM."]
    #[serde(default, skip_serializing_if = "serde_json::Map::is_empty")]
    pub sampling: serde_json::Map<String, serde_json::Value>,
}

On the serialization side, everything looks good, since these fields will not be present if empty. On the deserialization side, there's some unintended behavior, since the human-language specification seems to intend the presence of the sampling field to have meaning.

If Option<Map> becomes Map is a deliberate design choice, I could probably get away with using a custom typify::TypeSpaceSettings::with_map_type, but I figured I would ask here to be sure.