re: prior art: this sounds a lot like how email messages can be sent as text/plain and text/html. however, i’m concerned about using contentMap for this. the intention for contentMap seems to have been to allow for multiple language representations, and i’m not sure how that would interact with doing a contentMap by mimetype instead of by language.
therefore, i’d like to raise the following points:
- semantically,
mediaTypeis the property that is intended to be used for this, but this assumescontentinstead ofcontentMap. how might it be adapted to apply to objects with a map? - what realistic limits or best practices should apply to the keys of the map? the activity vocab spec uses MAY for language-tagged keys. afaik, the MAY indicates that implementations should be prepared to interoperate with contentMap containing language keys, but not anything else? the defined range is xsd:string or rdf:langString, so…
- what is the recommendation for choosing which of the keys to use as content out of the map? if the keys were languages, then it would be simple, but a simple hashmap isn’t expressive enough to express both mimetype and language unless some standardized behavior were introduced to the spec in a revision.
- to what extent should we prioritize or emphasize plaintext or html? note that in the email network, html messages have grown to be very annoying and mainly used for invasive ads and tracking, even leading several people to declare that html emails were a mistake and that emails should have remained plaintext. is a similar advisory prudent for activitypub? or is sanitization enough? and if sanitizing is enough, then surely only one html representation is needed per language? or are we going to see text/html and text/html-noblock?