Re: [w3c/manifest] Don't use enums, because they throw (#633)

Yeah I don't think letting error handling be up to user agents is a good idea.

What I said on #710:

> We can write a top-level rule that says "if the ECMAScript to IDL conversion throws a TypeError, the manifest is invalid", so it isn't meaningless that the conversion throws a TypeError outside of an actual JavaScript execution context. BUT the problem is that we don't want to trash the whole manifest if one member is invalid. If one member throws a TypeError, we generally want to ignore that member, not the whole thing.
>
> It seems that this isn't an issue with using IDL in a document format, but rather that IDL's conversion algorithm doesn't have a "non-strict mode" (that I know of). If there was a way to say "convert an ECMAScript object to IDL, with any TypeErrors in a dictionary member causing that member to be set as undefined". Or thereabouts. That would be perfectly usable in this spec.

@marcoscaceres response:
> That's really not feasible. We don't need to fork our IDL biding layer for this format.
>
> I think we need to go and figure out whatwg/infra#159

I agree if we can avoid using JavaScript conversion at all for these JSON documents, that would be good. But I do think we want to declare a complex JSON document format in a declarative language, not as an algorithm, and WebIDL seems the most appropriate.

We could also use [JSON Schema](http://json-schema.org/) which is specifically designed for this use case (but I'm not familiar with the details, and a quick scan of the documents doesn't seem to let us process a JSON object being lenient about invalid values; it's either valid or not).

-- 
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/633#issuecomment-415327486

Received on Thursday, 23 August 2018 08:01:16 UTC