@oblomov we are 20 years too late for that debate :/
Discussion
Loading...
there's a problem with media types in that they don't compose very well. you can only declare one Content-Type that might be more or less specific than the actual content's semantics. jsonld contexts don't compose easily, but at least they *can* be composed... sort of. so any json can be described by a jsonld context to "upgrade" it and allow it to work outside of closed worlds where everyone agrees. if you want to get rid of jsonld then you need to figure out how to compose media types.
or, otherwise, you need to figure out how to get everyone to agree to the same set of terms without ever declaring or defining those terms.
also you need to make one record per media type, and maybe mark every single one as rel=alternate of every other one.
this is doable if you have a single "app"/"domain"/processing model controlling the whole experience, with little-to-no overlap vs other app/domain/processing models.
there is power in agreement but agreeing is the hardest thing to do when there are other people involved. the best you can do in most cases is to map equivalences instead. is your blue my blue? what you call a Note is what i might call a Status. or rather, it's what you call a Status internally, but tell everyone else it's a Note, which is confusing when Note means something different to others.
i will maintain that most if not all of the problems that people in fedi dev attribute to "jsonld" are actually stemming from a lack of agreement on meaning while acting as if everyone agrees. i know this because people will say they ignore jsonld while making all the mistakes it's supposed to prevent. worse, if they don't ignore jsonld, they check for all the things they're not supposed to check for. it's like semantically attacking yourself -- knowing just enough to be dangerous to yourself.