Oh, please no. JSON is a data format. If you want a hypertext format there's HTML for that.
11 plus ones
Shared publicly•View activity
View 99 previous comments
- " But if we're only talking about naming conventions or conventions of cetain types of values (links, dates, ids, etc) that can be used in any application of json" < well, we weren't until (for whatever reason) this discussion veered off from being about how to do linking with JSON into how to handle metadata in a generalised and composable way that needs to be arbitrarily mixed into other media types.
This all-things-to-all-people, composable, meta-metadata fixation is precisely what is responsible for the character of XML that many people try to avoid when they opt for JSON.
JSON is 'simple' because of what you can't do with it, not what you can.
The issue of representing resources (and their links) on the web is not 'any old problem' - it's a general, fundamental problem for everyone on the web exposing their API with JSON (read: many people), and it can be solved in a general and simple way, with a new media type that introduces some additional constraint on top of JSON.
I am going to continue working on application/hal+json, bringing it into line with RFC5988 and possibly introducing Mark/Tim's _meta idea. Perhaps you could generalise the bits you want from that into a separate profile'able spec - which would give us the best of both worlds?Nov 30, 2011
- make that "whitespace separated"Nov 30, 2011
- ... I'm honestly seriously at a loss about what you're arguing against here because there seems to be a mismatch between what I've been suggesting and what you think I'm suggesting. The original discussion was about coming up with a convention for walking a document to harvest links, and about what new conventions needed to be put in place to do so precisely that. Part of that original conversation -- in Marks original post -- touched on the area of generalized metadata (the _meta block, the json-ld @context, the question over a profile param in the media type, etc). What I have suggested is nothing more than a consistent naming convention for this stuff and I've discussed how that naming convention can help address the problem in a way that is easily extended out to addressing other similar types of issues -- that is, we can address multiple similar issues with a single consistent approach that fits well within the parameters of the existing JSON model without requiring the invention of new media types, data models, extensions, or whatnot.
I honestly don't see how making statements like "JSON is simple because of what you can't do with it..." adds anything to the overall discussion. No one, as far as I can tell, has suggested anything that would even remotely alter the way JSON is used, or that would add even the slightest bit of additional complexity into the typical JSON processing model. People are already embedding links and metadata into JSON documents... why is it a problem to attempt to get people to do so in a consistent way?
On a technical level, what specifically about my proposal is throwing you off here? How does the naming convention fail to uphold the Spirit of JSON?Nov 30, 2011
- it's a question of practicality.
I'm proposing a standard media type that establishes a set of linking conventions for 'follow your nose' APIs. Whereas you seem (afaict) to be proposing a profile specification that establishes a set of conventions.. for establishing sets of conventions.
Do we really need coordination at that level, given that media type (or profile) specifications are actually consumed by people? What's the value proposition?Nov 30, 2011
- I'm kinda withhere -- let's not make this more complex than it needs to be. Having a convention for links at all is mostly for social benefit (e.g., showing people how to do it well, leveraging implementation, ease of use, less mental footprint) rather than technical.
The _meta thing is really just to help avoid collisions, and give tooling something to grab onto.
E.g., if _meta catches on, I can look for it with REDbot and start doing interesting things with JSON, without having to know the details of the format.Dec 1, 2011
- Pagination. Commenting. Content Alternates. Liking. Concrete enough?Dec 5, 2011