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

I really don't want to go down the route of either a) inventing a new schema language, b) forking a subset of WebIDL or another schema language, or c) using a schema language that isn't already part of the web platform. All three of those seem like a tremendous amount of work compared to just tweaking WebIDL for our needs.

FYI currently Chromium parses the manifest with a [hand-written algorithm](https://cs.chromium.org/chromium/src/content/renderer/manifest/manifest_parser.cc) which has all of the same issues as the old Manifest spec (very hard to read and easy to make mistakes). I would be hopeful that we can modify Chromium's manifest parser to use WebIDL just like we did in the spec, but this needs these fixes first.

OK, here are all the features of WebIDL that we use in the Manifest spec, or [Web Share Target](https://wicg.github.io/web-share-target/level-2/) (which is an extension of Manifest):

- Simple types `DOMString`, `USVString`, `boolean`.
- `enum`
- `sequence`
- `dictionary`
- `partial dictionary` (for easily extending in other specs)
- Optional and required dictionary members.
- Default values for dictionary members.
- "`or`" type clauses.
- Extended attributes / annotated types (to declaratively specify the extent of invalidation caused by type errors).
- Conversion from an ECMAScript value to an IDL value, of all of the above types. Includes a lot of type checking logic.

That's a huge chunk of WebIDL.

There's also quite a lot of functionality in WebIDL that we _don't_ need to define the Web App Manifest. A lot of the above discussion focuses on the fact that we aren't using the entire WebIDL spec, just the type conversion rules. I don't see this as any sort of argument to not use WebIDL. Specs depend on other specs all the time and use only a tiny fraction of the dependent spec's functionality. Pick any given web API and you'll probably find it uses a small subset of the WebIDL features. I don't see that as a reason for each web API to invent its own specification language with just the features it needs.

@domenic : 
> As an example, on a page where someone runs Object.prototype.short_name = "foo", using Web IDL would imply that parsing {} gives back a short name of "foo", not undefined. Again, you could add yet another extended attribute to fix that, but...

Yeah, as I said above, I think adding a `[StrictString]` extended type attribute would not be any different to the existing `[EnforceRange]` attribute for integers. TAG advice is to always use `[EnforceRange]` for integers, so why not add `[StrictString]` and recommend that all new interfaces use that? A desire to not convert {} to "[object Object]" is not unique to the manifest JSON file, and seems orthogonal to the suitability of WebIDL as a format for validating JSON.

Something I want to clear up with what I'm trying to do here:

@annevk :
> - A type-mismatch is equal to the field being set to undefined.

No, not always. At the top level, we want each member to only invalidate itself, but at lower levels, we have the flexibility to decide (note in #750 I don't add `[CatchTypeErrors]` to every member in every dictionary, just the top-level members).

I want to be able to annotate dictionary members and sequence elements on a case-by-case basis, so that we have the flexibility of deciding the granularity of errors (when a type error occurs, what level of the manifest does it invalidate?).

For example, in [Web Share Target](https://wicg.github.io/web-share-target/level-2/#extension-to-the-web-app-manifest), we are currently debating whether an error in a `files.accept` element should invalidate a) just that `accept` type, b) the entire `accept` array, c) the entire `file`, d) the entire `files` array, or e) the entire share target.

With `[CatchTypeError]`, we can easily (and readably) specify one of those five options by placing the `[CatchTypeError]` annotation on a) the `USVString` inside the `accept` sequence, b) the `accept` member of `ShareTargetFiles`, c) the `ShareTargetFile` inside the `files` sequence, d) the `files` member of `ShareTargetParams`, or e) just the `share_target` member of `WebAppManifest`.

So I'm not trying to universally change how type checking works in WebIDL. I'm trying to add a feature to WebIDL to let us override type checking behaviour as desired.

I think maybe @domenic you and I could have a VC offline to sync on this instead of a long public thread, then we can summarize here.

-- 
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-446472083