- From: Matt Giuca <notifications@github.com>
- Date: Thu, 23 Aug 2018 08:00:11 +0000 (UTC)
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/633/415327486@github.com>
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