{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/manifest/issues/611","repository_url":"https://api.github.com/repos/w3c/manifest","labels_url":"https://api.github.com/repos/w3c/manifest/issues/611/labels{/name}","comments_url":"https://api.github.com/repos/w3c/manifest/issues/611/comments","events_url":"https://api.github.com/repos/w3c/manifest/issues/611/events","html_url":"https://github.com/w3c/manifest/issues/611","id":258698039,"number":611,"title":"Use WebIDL to describe the manifest data structure","user":{"login":"mgiuca","id":228433,"avatar_url":"https://avatars0.githubusercontent.com/u/228433?v=4","gravatar_id":"","url":"https://api.github.com/users/mgiuca","html_url":"https://github.com/mgiuca","followers_url":"https://api.github.com/users/mgiuca/followers","following_url":"https://api.github.com/users/mgiuca/following{/other_user}","gists_url":"https://api.github.com/users/mgiuca/gists{/gist_id}","starred_url":"https://api.github.com/users/mgiuca/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mgiuca/subscriptions","organizations_url":"https://api.github.com/users/mgiuca/orgs","repos_url":"https://api.github.com/users/mgiuca/repos","events_url":"https://api.github.com/users/mgiuca/events{/privacy}","received_events_url":"https://api.github.com/users/mgiuca/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"mgiuca","id":228433,"avatar_url":"https://avatars0.githubusercontent.com/u/228433?v=4","gravatar_id":"","url":"https://api.github.com/users/mgiuca","html_url":"https://github.com/mgiuca","followers_url":"https://api.github.com/users/mgiuca/followers","following_url":"https://api.github.com/users/mgiuca/following{/other_user}","gists_url":"https://api.github.com/users/mgiuca/gists{/gist_id}","starred_url":"https://api.github.com/users/mgiuca/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mgiuca/subscriptions","organizations_url":"https://api.github.com/users/mgiuca/orgs","repos_url":"https://api.github.com/users/mgiuca/repos","events_url":"https://api.github.com/users/mgiuca/events{/privacy}","received_events_url":"https://api.github.com/users/mgiuca/received_events","type":"User","site_admin":false},"assignees":[{"login":"mgiuca","id":228433,"avatar_url":"https://avatars0.githubusercontent.com/u/228433?v=4","gravatar_id":"","url":"https://api.github.com/users/mgiuca","html_url":"https://github.com/mgiuca","followers_url":"https://api.github.com/users/mgiuca/followers","following_url":"https://api.github.com/users/mgiuca/following{/other_user}","gists_url":"https://api.github.com/users/mgiuca/gists{/gist_id}","starred_url":"https://api.github.com/users/mgiuca/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mgiuca/subscriptions","organizations_url":"https://api.github.com/users/mgiuca/orgs","repos_url":"https://api.github.com/users/mgiuca/repos","events_url":"https://api.github.com/users/mgiuca/events{/privacy}","received_events_url":"https://api.github.com/users/mgiuca/received_events","type":"User","site_admin":false}],"milestone":null,"comments":20,"created_at":"2017-09-19T05:10:05Z","updated_at":"2017-09-28T07:33:57Z","closed_at":null,"author_association":"COLLABORATOR","body":"There isn't really a formal specification of the manifest data structure. Instead, each member has its own section which describes the format of that member in prose. This makes it hard to discuss (e.g., in Ken's [shortcut proposal](https://gist.github.com/kenchris/0acec2790cd38dfdff0a7197ff00d1de), we'd like to be able to say \"`sequence<IconInfo> icons;`\" but there's no name for \"the dictionary that describes a Manifest icon\" because it's described in prose).\r\n\r\nI think we should add a WebIDL section that contains a dictionary definition for the full manifest, as a first step (I can do it).\r\n\r\nAs a second step, I think this would allow us to simplify the language in each individual member. The \"steps for processing a manifest\" algorithm could be replaced with \"Parse the JSON into an IDL dictionary value, then [convert it into an ECMAScript object](https://www.w3.org/TR/WebIDL-1/#es-dictionary)\" (which automatically applies all of the IDL type conversion rules).\r\n\r\nThen, for example, this text:\r\n\r\n> The steps for processing the short_name member is given by the following algorithm. The algorithm takes a manifest as an argument. This algorithm returns a string or undefined.\r\n>\r\n> 1. Let value be the result of calling the [[GetOwnProperty]] internal method of manifest with argument \"`short_name`\".\r\n> 2. If Type(*value*) is not \"string\":\r\n>     1. If Type(*value*) is not \"undefined\", issue a developer warning that the type is not supported.\r\n>     2. Return `undefined`.\r\n> 3. Otherwise, Trim(*value*) and return the result.\r\n\r\ncould be replaced by this (assuming `short_name` is a `DOMString`):\r\n\r\n> The steps for processing the short_name member is given by the following algorithm. The algorithm takes a manifest [referring to the processed ECMAScript object] as an argument. This algorithm returns a string or undefined.\r\n>\r\n> 1. Let value be the result of calling the [[GetOwnProperty]] internal method of manifest with argument \"`short_name`\".\r\n> 2. If Type(*value*) is not \"string\", return *value*.\r\n> 3. Otherwise, Trim(*value*) and return the result.\r\n\r\nWere it not for the call to Trim, this would make almost all the processing steps trivial. Unfortunately, almost all of them do Trim their strings, which makes things more complicated. Perhaps we could make a global rule that Manifest strings are trimmed, then we wouldn't really need any processing steps at all."},"comment":{"url":"https://api.github.com/repos/w3c/manifest/issues/comments/332753392","html_url":"https://github.com/w3c/manifest/issues/611#issuecomment-332753392","issue_url":"https://api.github.com/repos/w3c/manifest/issues/611","id":332753392,"user":{"login":"tobie","id":3392,"avatar_url":"https://avatars3.githubusercontent.com/u/3392?v=4","gravatar_id":"","url":"https://api.github.com/users/tobie","html_url":"https://github.com/tobie","followers_url":"https://api.github.com/users/tobie/followers","following_url":"https://api.github.com/users/tobie/following{/other_user}","gists_url":"https://api.github.com/users/tobie/gists{/gist_id}","starred_url":"https://api.github.com/users/tobie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tobie/subscriptions","organizations_url":"https://api.github.com/users/tobie/orgs","repos_url":"https://api.github.com/users/tobie/repos","events_url":"https://api.github.com/users/tobie/events{/privacy}","received_events_url":"https://api.github.com/users/tobie/received_events","type":"User","site_admin":false},"created_at":"2017-09-28T07:33:57Z","updated_at":"2017-09-28T07:33:57Z","author_association":"MEMBER","body":"> FWIW, I think it's worth doing this - if only because it gets rid of so much redundancy. But then again... I'm not sure how we reconcile the JSON naming vs DOM API naming issues.\r\n\r\nWe could add JSON bindings (I'm only half joking)."}}
{"actor":{"display_login":"tobie"}}