This issue is for discussion. It remains to be established through discussion whether any changes are required to the document.
At TPAC 2019, much was made by people in the Web platform community about identifying missing platform primitives. It seems that the idea that maps can only be constructed via JavaScript doesn't resonate with the Web platform community, to the point that they almost shut down discussion of maps as a feature.
What they emphasized, repeatedly, was the need to identify missing platform primitives, which can be built, possibly independently, and subsequently used to compose applications, including maps. Maps, and a map viewer, would seem to be almost complete applications, and as such, seem to be virtually out of scope for addition to the platform, unless framed in the missing platform primitives context.
I am aware that the document states that the objective is to break the functions down into bite-sized pieces:
For that reason, this review breaks web map functionality into very low-level capabilities.
I'm concerned that we aren't getting to a low enough level, although perhaps because I have been working on the <map> and <layer> and MapML element proposals, I am seeing the low level capabilities in a different light than what you all are arriving at by examining the behviour of map libraries.
For example, one "missing primitive" idea that seemed to resonate above others at TPAC seemed to be the notion of georeferenced coordinate systems being a missing primitive. The MapML proposal is fundamentally a proposal for a framework for standardizing the definitions of these coordinate systems so that Web sites can use them via element semantics. And elements of course have DOM APIs.
Now I personally don't see the use for georeferenced coordinate systems definitions without having element semantics (the geolocation api may be an exception), but perhaps I'm missing something. I'd appreciate all your thoughts on this issue here.
This issue is for discussion. It remains to be established through discussion whether any changes are required to the document.
At TPAC 2019, much was made by people in the Web platform community about identifying missing platform primitives. It seems that the idea that maps can only be constructed via JavaScript doesn't resonate with the Web platform community, to the point that they almost shut down discussion of maps as a feature.
What they emphasized, repeatedly, was the need to identify missing platform primitives, which can be built, possibly independently, and subsequently used to compose applications, including maps. Maps, and a map viewer, would seem to be almost complete applications, and as such, seem to be virtually out of scope for addition to the platform, unless framed in the missing platform primitives context.
I am aware that the document states that the objective is to break the functions down into bite-sized pieces:
I'm concerned that we aren't getting to a low enough level, although perhaps because I have been working on the
<map>and<layer>and MapML element proposals, I am seeing the low level capabilities in a different light than what you all are arriving at by examining the behviour of map libraries.For example, one "missing primitive" idea that seemed to resonate above others at TPAC seemed to be the notion of georeferenced coordinate systems being a missing primitive. The MapML proposal is fundamentally a proposal for a framework for standardizing the definitions of these coordinate systems so that Web sites can use them via element semantics. And elements of course have DOM APIs.
Now I personally don't see the use for georeferenced coordinate systems definitions without having element semantics (the geolocation api may be an exception), but perhaps I'm missing something. I'd appreciate all your thoughts on this issue here.