Re: [w3c/manifest] Type errors surrounding JSON "types" (#984)

I've been digging into this and I agree with Glen, we should do option 1.

Manifest processing steps currently convert a JavaScript object (erroneously referred to as a "JSON object", which isn't a thing defined in any spec) to an Infra ordered map. Instead, we should just start by calling [https://infra.spec.whatwg.org/#parse-json-bytes-to-an-infra-value](parse JSON bytes to an infra value), and then manifest processing would be converting an Infra ordered map to another ordered map.

Internally, it would still be going via a JavaScript object, but at least that would be an implementation detail of "parse JSON bytes to an infra value", and not something we deal with directly in Manifest.

Aside: I think that using the JavaScript parser to parse JSON is very fraught, especially if we ever rely on the order of map keys (which I'm not sure we do, but was being suggested in #975, though it looks like we won't be doing that in the latest proposal). I've only just now realised that the Manifest parser invokes [https://infra.spec.whatwg.org/#parse-json-bytes-to-a-javascript-value](parse JSON bytes to a JavaScript value) which invokes [https://tc39.es/ecma262/#sec-json.parse](JSON.parse) which invokes literally the entire JavaScript parser and evaluator. That means that technically to implement a Manifest parser (or any other JSON parser in the web platform), you are supposed to invoke JavaScript. I suspect most implementations (including Chromium's) won't do this, they'll use a normal JSON parser (example: [Chromium's Manifest parser](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/manifest/manifest_parser.cc?q=ParseJSON)).

That generally should return the same results, but won't in certain edge cases. One particular edge case is that numeric keys like `1` and `"2"` get sorted by JS's parser; they typically don't by a JSON parser, including Chromium's. This probably doesn't matter in Manifest (since we don't use numeric keys, and shouldn't rely on key order), but it's an example of the overwhelming complexity of using JS to parse JSON, as a requirement of the spec (especially for a format that's expected to be processed and generated by all sorts of tools, which may not have JS engines) resulting in slightly different output.

Anyway, with the current infrastructure we have, I don't see that changing, but at least we can take Glen's suggestion and hide away the fact that we're using JS values.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/984#issuecomment-859255084