I think it would be good if the mapml specification could be split into two parts: one part > focusing on the basic map conceptual structure of the map element and layer element,
To briefly summarize the MapML proposal: The
<mapml-viewer>, or map, identifies the coordinate reference system of the map, by declaring it via the projection attribute, and the location of the map viewport centre via its lat/lon/zoom attributes. The child layer element(s) may contain data inline, or reference the data via the layer src attribute. The only thing a layer element could contain, itself being HTML, is HTML, of course.
SVGMap has unique and useful features related to tile data, vector data, and WebApps associated with those layered data.
Of course, it would be interesting to extend these SVGMap features to map and layer elements. Also, a study towards this is the svg-map custom element described in the update above.
Indeed, it would be interesting to try to implement an SVGMap layer as the content of a MapML
<layer>content managed by SVGMap.js</layer>, maybe even as
<svgmap-layer></svgmap-layer>, possibly even today, but certainly as part of the overall goal.
Integrating a custom element version of a mapping framework (SVGMap.js) with another custom element version of a different mapping framework (Leaflet.js or any other) would be hard due to the degree that we are ‘faking it’, or making a façade of a native
<mapml-viewer> implementation in our polyfill, and the challenge requires us to look together to see if it is actually possible, even as a concept demonstration. This challenge is the fundamental lack of interoperability that we see today between Web mapping frameworks, and is one of the central challenges for which a native
<mapml-viewer> element in HTML would provide a technical solution.
However, this (making a custom element layer ‘renderer’, in the “creates HTML/SVG elements sense of the word ‘rendering’”) is perfectly in scope for the full proposal, I believe, and could have the merit of ‘staging’ the overall proposal, allowing it to be useful to SVGMap.js users from the start. Also other Web mapping frameworks which decide to support rendering content into
<layer>s – I don’t see why they all wouldn’t want to. I think that what a scaled-back (stage) of the proposal misses (and needs) is the purely declarative approach of MapML-HTML which includes real-world feature/object semantics (an accessibility requirement), but maybe it would be a good way to get started building the
<map> <layer> </layer></map> infrastructure that would set up the basic map / coordinate reference system semantics, with real-world feature/object semantics temporarily, or for the interim, polyfilled by custom script-rendered SVG.
The key primitive capabilities that are required for the scaled back / staged proposal seem to be: browser CRS infrastructure and DOM layer rendering (pan/zoom) support.