Re: [w3c/manifest] Drop WebIDL enums (#899)

> @mgiuca First of all, thanks for your feedback! I’ve seen your changes in #750 after I created this PR, are they related somehow?

Yeah, #750 (thanks for finding this) is what I had in mind when I said "define slightly different parsing rules for WebIDL but keep the same representation". As I recall, that was rejected. @annevk said on https://github.com/heycam/webidl/pull/597 that we could use https://infra.spec.whatwg.org/#parse-json-into-infra-values, but I don't see how that addresses the error problem.

What I was trying to capture with that "[CatchTypeError]" annotation was a declarative way of defining the "limit" of errors. Because we don't just want to say "any manifest field that doesn't have the correct type should just be dropped", because for example if an ImageResource has a bad URL, the whole ImageResource should be dropped, not just the URL field. So we need to manually define on a case-by-case basis the "scope" where failure stops.

It looks silly in my patch that every single element has `[CatchTypeError]` on it. But there's a reason to this. For example, look at icons:

```webidl
[CatchTypeError] sequence<[CatchTypeError] ImageResource> icons;
```

That says if any icon is invalid, the failure bubbles up to the whole ImageResource and we drop that item from the list. But also, if `icons` itself is the wrong type (say, an int), then we drop the icons object, rather than erroring out the whole manifest.

I still like this approach. I think it's better than scrapping the whole WebIDL for hand-written algorithms, or another schema language. We have WebIDL, a beautifully defined way to express a typed data structure that everyone working on the web platform can read and write. I'd rather embrace it than abandon it, simply because we don't have a good way of describing how errors should propagate.

-- 
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/pull/899#issuecomment-643086056