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

I've become increasingly uncomfortable with using WebIDL to spec the manifest format. I think it seemed like a great idea at the time, but for the reasons @domenic mentioned, and the issues we've hit in practice, we need to seriously re-evaluate what we have done here. I'm also super worried that other groups have started imitating us, and those groups have far less experience with WebIDL than we do (they are going to get themselves into a world of hurt). 

As @annevk points out, we have a few options. When we started this project, I deliberately chose not to use any schema language because we'd had such a terrible experience with XML/XML Schema, XHTML+DTDs, RDF etc. that it seemed pointless to define yet another schema language. Rather, it seemed like just writing our own processing rules using prose would make more sense - even if it turned out to be more long winded. 

In implementation, the parsing rules were supposed to be consistent. Consider, Gecko's "[ValueExtractor](https://github.com/mozilla/gecko-dev/blob/master/dom/manifest/ValueExtractor.jsm#L34)" that pulls any value from the manifest using the same algorithm (19 lines of code). 

And each one of our members gets [extracted consistently]( 
https://github.com/mozilla/gecko-dev/blob/master/dom/manifest/ManifestProcessor.jsm#L87) too, for example, each rule looks like this:

```JS
    function processOrientationMember() {
      const spec = {
        objectName: 'manifest',
        object: rawManifest,
        property: 'orientation',
        expectedType: 'string',
        trim: true
      };
      const value = extractor.extractValue(spec);
      if (value && typeof value === "string" && this.orientationTypes.has(value.toLowerCase())) {
        return value.toLowerCase();
      }
      return undefined;
    }
```

We could go back and generalize the processing rules to make something simple and consistent like the above - which handles special case processing for particular members (basically @annevk's requirements). Or we could look at Chrome and WebKit's implementation, to see if either team has come up with something clever, concise, and consistent.  

If we end up with a generalized model for the Web, than that's great (and we can push it to Infra or make a new spec)... but I don't know if that should be a goal just yet.   

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