Re: [w3c/manifest] Use WebIDL to describe the manifest data structure (#611)

> If you just want an overview of all JSON members and their corresponding types, have you considered creating a table?

That would be preferable to what we have now, but not convey as much information as IDL. A couple of points:

1. IDL not only gives us syntax for describing the type of a bag of named fields, but it also gives us semantics for how to process it. For example, how to convert values that are not of the expected type, default values, etc. We could certainly specify all that in prose (mentioning the table), but why do that when the IDL processing model is already well understood?
2. It's possible that manifest parsing code (in the implementation) would be much more robust, standards-compliant and simpler, if it was based on existing IDL parsers rather than hand-coded logic. Of course, the implementor is free to do it this way regardless of whether it's specced as IDL, but it would be easier to build and make sure you had it right if you could just copy+paste IDL from the spec into the implementation (as we do with other APIs).

> 
> If you actually want to use IDL, how exactly would that work? You would first convert bytes to code points. Then code points to JSON values. Then JSON values to ECMAScript values and then feed that to the dictionary parser to get an IDL dictionary?

Yes, I think so. Implementations could cut out some of those steps but I think that's how the spec would go.

> I don't see any such processing model defined at the URL you pointed to.

Not yet. Kenneth just wanted to capture the IDL initially, and in a follow-up work on rewriting the parsing logic to use the IDL primitives instead of manually parsing. What is your overall opinion on whether this is worth it?

-- 
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/611#issuecomment-332730263