Processing steps change the types of things (type errors)

[mgiuca]

Spun off from w3c/image-resource#8.

It seems there are "type errors" (in a spec sense, not like JavaScript TypeError problems) all over the manifest spec, since we process various members, changing their type, and store them back in the manifest WebIDL structure.

For example, start_url:

• It's specified as USVString start_url in the WebAppManifest WebIDL dictionary.
• The steps for processing the start_url member convert the USVString into a URL object, returning the URL.
• The steps for processing a manifest say "Set manifest["start_url"] to the result of running processing the start_url member", technically storing a URL object in a field of type USVString.

This sort of type error happens everywhere where a processing step changes the type of a member. They noticed it in the Image Resource spec, and the solution there was to define a "processed image resource" structure, capable of holding the transformed types. If Manifest were to switch over to using the Image Resource spec, we would now be forced to shove a "sequence of processed image resource" in several fields of type sequence<ImageResource>, but that wouldn't be any worse than the existing type errors.

Ideally, we would similarly define a "processed web app manifest", but that would be quite a lot of work and redundancy in the spec, which I'm not sure we want to maintain. A quick hand-wavey solution may be to update the existing term "processed manifest" to say that it is a structure with the same members as WebAppManifest, but whose types may be different, for example start_url is a URL, not a USVString.

[marcoscaceres]

In 32b497c, I (finally) got rid of the IDL and converted the "processed manifest" to an (Infra) ordered map. It now just uses/checks JSON types.