per this message #236 (comment) , I'm wondering whether all content objects should be simply { mimeType: , content: }

this would simplify and reduce confusion around text vs image content, and allow easy extension to video ( is it an image content or encoded text content? ), audio, etc.

I was thinking about something like that as well: #90 (reply in thread)

However, my current thought is that it's useful to distinguish text content versus binary content without having to check the MIME type. So, instead, I would advocate having two types:

interface TextContent {
  mimeType?: string; // Assumed "text/plain" if not present
  text: string; // UTF-8 encoding
  annotations?: Annotations;
}

interface BlobContent {
  mimeType: string;
  blob: string; // Base64 encoding
  annotations?: Annotations;
}

Also, instead of changing EmbeddedResource, I think we should remove it, since its primary role would be fulfilled by BlobContent. Then we can add Resource as a content type in order to support uri-based content (see #603 (comment)).

In summary: the three content types would be TextContent, BlobContent, and Resource, distinguishable via their text, blob, and uri properties, respectively.

I haven't given any thought to handling backward compatibility though. 😉

@jonathanhefner I love that. I'll sketch it here, while attempting to address backward compatibility:

Text

Deprecate

interface TextContent {
  type: "text";
  /* <left-out-by-oversight> */
  mimeType?: string; // Assumed "text/plain" if not present
  /* </left-out-by-oversight> */
  text: string;
  annotations?: Annotations;
}

Note: mimeType can be shoved in as a first step before removing type. Or we can directly skip to the end.

Do instead

interface TextContent {
  mimeType?: string; // Assumed "text/plain" if not present
  text: string; // UTF-8 encoding
  annotations?: Annotations;
}

Image & Audio

Deprecate

interface ImageContent {
  type: "image";
  data: string;
  mimeType: string;
  annotations?: Annotations;
}

interface AudioContent {
  type: "audio";
  data: string;
  mimeType: string;
  annotations?: Annotations;
}

Do instead

interface BlobContent {
  mimeType: string;
  blob: string; // Base64 encoding
  annotations?: Annotations;
}

Backwards compatibility for the above

When type is set to "text" or "image" or "audio", either ignore or error on a paradoxical mimeType whose main type does not match type.

Embedded Resources

Deprecate

interface EmbeddedResource {
  type: "resource";
  resource: {
    uri: string;
    mimeType?: string;
    /* <one-of> */
    text: string;
    /* <or /> */
    blob: string;
    /* </one-of> */
  },
  annotations?: Annotations;
}

Do instead

interface Resource {
  uri: string;
  mimeType?: string;
  /* <one-of> */
  text?: string;
  /* <or /> */
  blob?: string;
  /* </one-of> */
  annotations?: Annotations;
}

So it can be valid to have a Resource with only uri. The rest can be determined when the resource is fetched from the URI.
Optionally, the "current" version of the resource can be embedded by including mimeType and (text or blob).

Backwards compatibility for resources

When type is set to "resource", error if uri is missing.

Unified type def

Maybe it's as simple as:

interface TextContent {
  mimeType?: string; // Assumed "text/plain" if not present
  text: string; // UTF-8 encoding
}

interface BlobContent {
  mimeType: string;
  blob: string; // Base64 encoding
}

type Content = (TextContent | BlobContent) & {
  type?: string; // Deprecated, kept for backwards compatibility
  uri?: string; // Presence makes this a Resource
  annotations?: Annotations;
}

^ We should probably take this to a new thread.

Moved here: #674