{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/dpub-pwp-ucr/issues/107","repository_url":"https://api.github.com/repos/w3c/dpub-pwp-ucr","labels_url":"https://api.github.com/repos/w3c/dpub-pwp-ucr/issues/107/labels{/name}","comments_url":"https://api.github.com/repos/w3c/dpub-pwp-ucr/issues/107/comments","events_url":"https://api.github.com/repos/w3c/dpub-pwp-ucr/issues/107/events","html_url":"https://github.com/w3c/dpub-pwp-ucr/issues/107","id":176802477,"number":107,"title":"2.12 Essential and Non-essential Resources","user":{"login":"marcoscaceres","id":870154,"avatar_url":"https://avatars.githubusercontent.com/u/870154?v=3","gravatar_id":"","url":"https://api.github.com/users/marcoscaceres","html_url":"https://github.com/marcoscaceres","followers_url":"https://api.github.com/users/marcoscaceres/followers","following_url":"https://api.github.com/users/marcoscaceres/following{/other_user}","gists_url":"https://api.github.com/users/marcoscaceres/gists{/gist_id}","starred_url":"https://api.github.com/users/marcoscaceres/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/marcoscaceres/subscriptions","organizations_url":"https://api.github.com/users/marcoscaceres/orgs","repos_url":"https://api.github.com/users/marcoscaceres/repos","events_url":"https://api.github.com/users/marcoscaceres/events{/privacy}","received_events_url":"https://api.github.com/users/marcoscaceres/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2016-09-14T03:00:11Z","updated_at":"2016-09-14T08:01:03Z","closed_at":null,"body":"> However, having a clear indication within the publication format to mark which items are critical, and which instead need a fallback for limited. \r\n\r\nThis again tries to enforce hard requirements where there are none. There is a business case (in the programming sense) for marking resources as critical - but these are provided programmatically by, for example, putting those resources in the \"REALLY_REALLY_IMPORTANT_CACHE\". "},"comment":{"url":"https://api.github.com/repos/w3c/dpub-pwp-ucr/issues/comments/246935989","html_url":"https://github.com/w3c/dpub-pwp-ucr/issues/107#issuecomment-246935989","issue_url":"https://api.github.com/repos/w3c/dpub-pwp-ucr/issues/107","id":246935989,"user":{"login":"marcoscaceres","id":870154,"avatar_url":"https://avatars.githubusercontent.com/u/870154?v=3","gravatar_id":"","url":"https://api.github.com/users/marcoscaceres","html_url":"https://github.com/marcoscaceres","followers_url":"https://api.github.com/users/marcoscaceres/followers","following_url":"https://api.github.com/users/marcoscaceres/following{/other_user}","gists_url":"https://api.github.com/users/marcoscaceres/gists{/gist_id}","starred_url":"https://api.github.com/users/marcoscaceres/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/marcoscaceres/subscriptions","organizations_url":"https://api.github.com/users/marcoscaceres/orgs","repos_url":"https://api.github.com/users/marcoscaceres/repos","events_url":"https://api.github.com/users/marcoscaceres/events{/privacy}","received_events_url":"https://api.github.com/users/marcoscaceres/received_events","type":"User","site_admin":false},"created_at":"2016-09-14T08:01:03Z","updated_at":"2016-09-14T08:01:03Z","body":"> (First of all, nobody is talking about RDF or XML or even JSON. Can we get that off the table?)\r\n\r\nI can smell a new format from a mile away :) But ok. \r\n\r\n> At that point, we are collecting use cases and requirements. If it so happens that current technology can solve this requirement, then be it. Everybody is happy and we can move on, but that does not invalidate the requirement itself.\r\n\r\nSure, but each requirement seems to strongly hint at a presupposition. \r\n\r\nWhat would be cool would be to add after each requirement: \"Currently addressed by: Web Spec X\".  \r\n\r\nWhere there is no \"Web Spec X\" found, then we've hit the standardization jackpot. \r\n\r\n> I must admit, but that may be only my limited understanding of the world, that I do not see how the cache API can decide, by itself, that it can safely drop a resource in a specific environment without jeopardizing the information content that the publication is trying to convey. But again, if that can be solved, fine!\r\n\r\nIt can't on its own... but JavaScript code that decides what gets put into, or pulled out of, the cache can make those decisions. "}}
{"actor":{"display_login":"marcoscaceres"}}