# Decoding different versions of content structure **URL:** \ **Category:** Foundation\ **Created:** [November 18, 2024, 6:03pm UTC](https://forums.swift.org/t/decoding-different-versions-of-content-structure/76100 "2024-11-18T18:03:31Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![Stiivi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stiivi/32/495_2.png) [@Stiivi](https://forums.swift.org/u/Stiivi)\ **Post date:** [November 22, 2024, 11:19am UTC](https://forums.swift.org/t/decoding-different-versions-of-content-structure/76100/6 "2024-11-22T11:19:00Z")
I agree with what you said. I considered `JSONSerialization`, that was the reason for [this question](https://forums.swift.org/t/low-level-json-api-idea/71704). It is still not in the new open-source swift Foundation though (which is another constraint). In the future I would like to add reading of more variety of JSON structures. Having data warehousing and data quality background, I do not trust anything that is foreign. Sometimes added complexity is necessary to either make the reading more tolerable (with sensible defaults and default transformations) or at least to give me and the user more precise error information with potential contextual/semantic hints. Raw JSON gives that possibility for the cost of added complexity. `Codable` is great for structures that I have full control of, especially if I am their originator. It is also great for ephemeral data, that live just enough to be moved around. Not so great for something that is intended for long term storage where the original application is expected to evolve or when there might be different "foreign" applications producing the data. However, reading foreing structuers is tangential topic to this post, I diverted slightly. --- _[View the full topic](https://forums.swift.org/t/decoding-different-versions-of-content-structure/76100)._