{"action":"created","issue":{"url":"https://api.github.com/repos/opengeospatial/D012-MapML_Engineering_Report/issues/23","repository_url":"https://api.github.com/repos/opengeospatial/D012-MapML_Engineering_Report","labels_url":"https://api.github.com/repos/opengeospatial/D012-MapML_Engineering_Report/issues/23/labels{/name}","comments_url":"https://api.github.com/repos/opengeospatial/D012-MapML_Engineering_Report/issues/23/comments","events_url":"https://api.github.com/repos/opengeospatial/D012-MapML_Engineering_Report/issues/23/events","html_url":"https://github.com/opengeospatial/D012-MapML_Engineering_Report/issues/23","id":338304230,"node_id":"MDU6SXNzdWUzMzgzMDQyMzA=","number":23,"title":"Why should browsers implement MapML natively without it being fully implemented as a set of custom elements?","user":{"login":"prushforth","id":2437285,"node_id":"MDQ6VXNlcjI0MzcyODU=","avatar_url":"https://avatars0.githubusercontent.com/u/2437285?v=4","gravatar_id":"","url":"https://api.github.com/users/prushforth","html_url":"https://github.com/prushforth","followers_url":"https://api.github.com/users/prushforth/followers","following_url":"https://api.github.com/users/prushforth/following{/other_user}","gists_url":"https://api.github.com/users/prushforth/gists{/gist_id}","starred_url":"https://api.github.com/users/prushforth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/prushforth/subscriptions","organizations_url":"https://api.github.com/users/prushforth/orgs","repos_url":"https://api.github.com/users/prushforth/repos","events_url":"https://api.github.com/users/prushforth/events{/privacy}","received_events_url":"https://api.github.com/users/prushforth/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-07-04T14:48:50Z","updated_at":"2018-11-19T17:47:23Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I am creating this issue to stimulate discussion on this topic, because I / we need to make the business case clear for browser developers / makers, and this is the central question that they will be asking, IMO.\r\n\r\nJust to be clear, there is a [publicly available](https://www.webcomponents.org/element/Maps4HTML/Web-Map-Custom-Element) [open source implementation](https://github.com/Maps4HTML/Web-Map-Custom-Element) of [MapML as a set of custom elements](http://geogratis.gc.ca/api/beta/mapml/en/cbmtile/).  This implementation provides a good idea of how standardized maps in the browser might/should behave _**from the point of view of the user**_.  What they _don't_ do is implement a MapML DOM, which is what a JavaScript developer would expect of MapML.\r\n\r\nMapML has been crafted to \"[pave the cowpaths](https://www.w3.org/TR/html-design-principles/#pave-the-cowpaths)\", in the words of the HTML Design Principles.  \r\n\r\nIt is a vocabulary that derives from HTML, which is obviously more than a cowpath.  It standardizes the semantics of maps as they are found on the Web today, to the extent possible.  So \"maps\" are another cowpath (more of a logging road, actually).  \r\n\r\nThere is however, a chicken and an egg situation with MapML; in order for it to gain widespread use, it needs to a) be produced by mapping services, or at least be easily created to refer to mapping services without having to modify those services and **b) have one or more clients to consume it.**  \r\n\r\nWe are doing our best to make it easy to (per a, above) create MapML.  Hopefully, and with a little bit of promotion / support, mapping (and WFS) services will quickly implement it as a format offering.  At the very least, a MapML document can easily be hand-crafted to refer to mapping services.  Feature services may need to support it directly, since their return type is not a pre-defined media type.\r\n\r\nWhich leaves us with: **b) one or more clients to consume it.** That's what I would like this issue to discuss.\r\n\r\nBecause MapML is (X)HTML, it is not an ideal format for JavaScript developers to process.  Indeed, JavaScript developers are intended to be the secondary consumers of MapML; the browser parsing and layout (and security) engine should be the primary recipient, with DOM APIs forming the bedrock standards foundation on which JavaScript programs can rely.\r\n\r\nBrowser developers and associated teams have been working for (6 or more) years on standardizing and implementing Web Components, the set of technologies which include and underpin Custom Elements. Custom Elements are often touted as the path to standardization for new concepts / ideas for markup.  The notion is that Web developers will 'like' a component and vote with their feet and include it in their Web pages.  Eventually, the common crawl will reveal that a component has enough 'traction', and it can be standardized.  That's the theory, anyway. \r\n\r\nThe components should expose a DOM / event API that JavaScript developers can work with.  I contend that once a company has invested in developing programs to an API, they are bound to it, essentially forever, because the costs of leaving exceed the costs of staying.  This is the (successful) model behind proprietary software. Standard APIs are no different, including standard DOM APIs, it's just that they're, well, standard.  In light of this fact, I think that a full, high-fidelity **custom elements** implementation of the MapML vocabulary that implements a DOM API, **_if it were to become successful, or visible / notable in the common crawl_**, would be detrimental to the goal of standardizing maps in browsers, because people would have already invested in programming to that API, and that API might not be the final standard. \r\n\r\nA more sensible path IMO, will be to (temporarily) finalize MapML, prototyping its **user** behaviour via our custom elements; once that behaviour is acclaimed as appropriate, one or two browsers should consider native (or even custom elements-based) implementations of the DOM API for the vocabulary.  I don't believe it's fair to expect widespread adoption of this API before it is standardized, but I do think it needs to be developed in a way that a) it is agreed to by > 1 browser maker and b) develops Web Platform Tests that assure its behaviour in the Web Platform.\r\n\r\nWhat do you think?\r\n"},"comment":{"url":"https://api.github.com/repos/opengeospatial/D012-MapML_Engineering_Report/issues/comments/439981582","html_url":"https://github.com/opengeospatial/D012-MapML_Engineering_Report/issues/23#issuecomment-439981582","issue_url":"https://api.github.com/repos/opengeospatial/D012-MapML_Engineering_Report/issues/23","id":439981582,"node_id":"MDEyOklzc3VlQ29tbWVudDQzOTk4MTU4Mg==","user":{"login":"joanma747","id":5230444,"node_id":"MDQ6VXNlcjUyMzA0NDQ=","avatar_url":"https://avatars0.githubusercontent.com/u/5230444?v=4","gravatar_id":"","url":"https://api.github.com/users/joanma747","html_url":"https://github.com/joanma747","followers_url":"https://api.github.com/users/joanma747/followers","following_url":"https://api.github.com/users/joanma747/following{/other_user}","gists_url":"https://api.github.com/users/joanma747/gists{/gist_id}","starred_url":"https://api.github.com/users/joanma747/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joanma747/subscriptions","organizations_url":"https://api.github.com/users/joanma747/orgs","repos_url":"https://api.github.com/users/joanma747/repos","events_url":"https://api.github.com/users/joanma747/events{/privacy}","received_events_url":"https://api.github.com/users/joanma747/received_events","type":"User","site_admin":false},"created_at":"2018-11-19T17:47:23Z","updated_at":"2018-11-19T17:47:23Z","author_association":"CONTRIBUTOR","body":"To me the main reason is CORS. An implementation by the browser can be considered a \"trusted\" implementation that will only render data in the screen and will not do nasty things. If web browsers implements MapML that will be an enormous competitive advantage compered with current technologies that are contained by CORS."}}
{"actor":{"display_login":"joanma747"}}