From 60e0e156cc8fda3eea3f1ff31da0f8fb9a1e4cff Mon Sep 17 00:00:00 2001 From: Peter Rushforth Date: Mon, 16 May 2022 16:58:27 -0400 Subject: [PATCH 1/2] Revise and simplify top level explainer. --- README.md | 236 +++++++++++++++++++++++---------------- images/layer-element.png | Bin 76166 -> 357051 bytes images/map-element.png | Bin 38148 -> 436220 bytes 3 files changed, 140 insertions(+), 96 deletions(-) diff --git a/README.md b/README.md index cf29ae6..b979414 100644 --- a/README.md +++ b/README.md @@ -8,149 +8,193 @@ Peter Rushforth

Participate

-The W3C [Maps for HTML Community Group](https://www.w3.org/community/maps4html/) -is iterating on the problem space. -You can contribute to the on-going discussion and documentation of -[Use Cases and Requirements for Standardizing Web Maps](https://maps4html.org/HTML-Map-Element-UseCases-Requirements/). -Alternatively, if your organization is a member of the -[Web Platform Incubator Community Group](https://www.w3.org/community/WICG/) (WICG) -and you are able to contribute there but not elsewhere, -please consider contributing through the [WICG forum on Web mapping](https://discourse.wicg.io/c/web-mapping/22). +The W3C [Maps for HTML Community Group](https://www.w3.org/community/maps4html/) +is iterating on the problem space. +You can contribute to the on-going discussion and documentation of +[Use Cases and Requirements for Standardizing Web Maps](https://maps4html.org/HTML-Map-Element-UseCases-Requirements/). +Alternatively, if your organization is a member of the +[Web Platform Incubator Community Group](https://www.w3.org/community/WICG/) (WICG) +and you are able to contribute there but not elsewhere, +please consider contributing through the [WICG forum on Web mapping](https://discourse.wicg.io/c/web-mapping/22). We would love to hear from you. [Issue tracker for this explainer](https://github.com/Maps4HTML/MapML-Proposal/issues)

Introduction

-Web maps are a well-established domain of Web design, and there exist popular, mature open and closed source JavaScript libraries to create and manage Web maps. JavaScript web maps are often containers for publicly available and funded open geospatial and statistical data. Yet despite established JavaScript libraries and server-side API standards, Web maps remain a complex Web niche that is difficult to learn, due to their extensive prerequisite knowledge requirements. As a result, there exists a community of Web map developers which contributes very little to the Web platform and which may possess little understanding that the Web exists as a distinct and standards-based platform. Similarly, the Web platform seems mostly oblivious to Web maps and their requirements, and provides no direct support for maps. In other words, Web maps existence in the Web platform depends on intermediaries which “abstract away” the Web platform. +Web maps are a well-established class of Web application, and there exist popular, +mature open- and closed-source JavaScript frameworks to create and manage Web maps. +Web maps, considered from the perspective of the Extensible Web Manifesto, represent +a “high-level API”. The many low-level browser APIs already used by the popular +JavaScript mapping frameworks demonstrate that Web maps may be a good fit for +inclusion into the Web platform standards at this time. -The goal of this proposal is to bridge the gap between the two communities in a way that may have positive benefits for both sides. On the one hand, the Web mapping community is burdened by intermediaries and the consequent barriers to widespread creation and use of maps and public map information. On the other hand, the Web platform, especially the mobile Web, needs more and better high-level features and less JavaScript. Simple yet extensible Web maps in HTML, that equally leverage the other platform standards, is the feature that both communities need to come together to improve usability and accessibility for users. +MapML is the declarative API that results from our community’s effort to abstract +and polyfill Web mapping requirements as custom elements, using one of the mature +open source Web mapping frameworks so as to not have to start “from scratch”. +The process of polyfilling Web maps as MapML has also identified missing low-level +platform APIs that will be essential to complete the implementation of Web maps +as a standard platform feature.

Contents

- [The Problem](#the-problem) - [The Proposal](#the-proposal) - - [Goals](#goals) - - - [A High-Level API](#a-high-level-api) - - [Key Scenarios](#key-scenarios) +- [Goals](#goals) +- [Use Cases and Requirements](#use-cases-and-requirements) +- [Key Scenarios](#key-scenarios) - [Detailed design discussion](#detailed-design-discussion) - - [Use Cases and Requirements](#use-cases-and-requirements) - - [W3C/OGC Joint Workshop on Maps for the Web](#w3c-ogc-joint-workshop-on-maps-for-the-web) - [Considered Alternative Designs of MapML](#considered-alternative-designs-of-mapml) -- [Alternative Approaches](#alternative-approaches) - [Stakeholder Feedback / Opposition](#stakeholder-feedback--opposition) - [References and Acknowledgements](#references-and-acknowledgements)

The Problem

-Web maps today are created using a wide range of technology stacks on both the client and server, some standard, some open, and some proprietary. The complexity of choices and the wide variety of technologies required to create Web maps results in maps of highly variable usability and accessibility. This has in turn led to the creation of centralized mapping services, that may or may not be implemented using Web technology; in some cases, mapping services which work well on desktop Web browsers mostly bypass the mobile Web through creation of mobile platform mapping apps, where the ‘rules of the Web platform’ (such as device permissions) do not apply. Some centralized mapping services, both on the Web but especially on mobile technology platforms, are constructed for the purpose of tracking the user’s location and their locations of (search) interest, and using that private location information to market and re-sell highly targeted advertising. - -The problem to be solved, therefore, is to reduce the threshold complexity of creating accessible, usable and privacy-preserving Web maps, and to enable full use of Web platform standards such as HTML, URL, SVG, CSS and JavaScript in map creation, styling, presentation and interaction. +Web maps are not interoperable. +For example, users cannot “mash up” a Leaflet map and an OpenLayers map, two of +the most popular open source Web mapping frameworks, even if they show the same +exact data source in the exact same location. (The situation is even more +non-interoperable between open map data and privately managed map databases, +where the sole client may be that provided by the owner of the map data. The +lack of legal interoperability of map data is outside the scope of standardization.) + +The lack of Web map interoperability affects developers. The skill set and +vocabulary required to create a robust map is different from one mapping framework +to the next. They can be complex to create, +with visual styling of map information being a discipline that is generally +outside the realm of Web technology, and different from one mapping framework to +the next. + +Web maps are [typically not accessible](https://github.com/Malvoz/web-maps-wcag-evaluation/blob/master/README.md). +The knowledge required to use Web +maps is different for each framework, with resulting accessibility challenges +arising from inconsistencies in user experience across frameworks. + +Location information is not searchable, +except through specialized portals. Web maps are not crawlable; even if the JavaScript +that creates a Web map is executed by a crawler, the resulting DOM requires a +sighted user to interpret it, because it only has visual semantics. The DOM created +also varies from framework to framework. As a result, users cannot search for +location information, embedded as it is in program code, except in specialized +mapping portals. Location search may be even more important for non-visual users +especially in a mobile context, but it is impossible because of today’s Web mapping +frameworks.

The Proposal

-To solve the problem, our approach is to identify the Web map processing that is currently performed by JavaScript libraries which should instead be defined - in accordance with the Web Platform Design Principles - as elements and attributes supported by CSS, while at the same time, we identify the Web map processing that should remain in the JavaScript domain as a standardized DOM API. By building the core behaviour of maps and layers into HTML, Web authors who want to build simple maps into their pages can easily do so, supported by core platform technologies, with the power of JavaScript available to enhance the core map and layer behaviour. - -By lowering the barriers for Web map authors in this way, we will improve the usability, and standardize the accessibility of Web maps. Through making map creation a matter of applying appropriately crafted Web platform standards, we will create the conditions to multiply the choices of mapping services offered to authors and users of the Web. +The proposal is to create accessible, searchable and usable Web maps, by integrating +mapping elements into HTML supported by the CSS and DOM standards. -In improving the choices among mapping services available through the Web platform, we will enable the growth of services that offer alternate means of paying for maps other than in exchange for the user’s personal private information, and we will enable standardized Web map accessibility through addition of maps to HTML. Finally, by making it cheaper to create Web maps than to build mobile apps, we will improve the business rationale for choosing the mobile Web as a development platform, and in doing so we hope the (mobile) Web will benefit from increased ‘success’, or network effects. +This extension to HTML would create a `<map>/<mapmlviewer>*` viewer widget +that contains default controls in a user agent shadow root, (similar to `<video>` +today), with child `<layer>` elements which are light DOM, which may either +refer to remote map source or contain map-related markup (the vocabulary of which +is also part of this proposal): -

Goals

- -- Define the means to allow authors to create dynamic, -usable and accessible Web maps about as easily as they can embed an image, -a video or a podcast today. -- Define and embed accessibility of map feature and location information into -HTML for use by screen readers and other assistive technology. -- Define and design security of map information considerations into the Web -platform. -- Define the markup to create mapping mashups that doesn’t necessarily require -scripting or detailed mapping server technology knowledge -i.e. that can be accomplished about as easily as linking to a document. -- Simplify the use of public -[spatial data infrastructures](https://en.wikipedia.org/wiki/Spatial_data_infrastructure) -(SDI), such as -[OpenStreetMap](https://wiki.openstreetmap.org/wiki/Main_Page) -and national and international SDIs, -by designing the integration of those services into the proposed Web platform -mapping standards. -- Defining and (advocate for) adding map-enabled HTML to the serialization -formats available from existing spatial (map) content management systems, -APIs and Web Services. - - - -

A High-Level API

- -The Extensible Web Manifesto calls for iterative development and evolution of platform features, starting with low-level ‘primitives’ and resulting eventually in high-level features. Although there are several low-level primitive proposals inherent or implicated in this proposal, overall this can be seen as a proposal for a high-level feature. That feature is declarative dynamic Web maps in HTML. Web mapping is a mature category of JavaScript library that is well into the stage of its development life cycle that some of the aggregate characteristics of those libraries should be incorporated into the platform. As such, this proposal captures some of the ‘cow paths’ of open and closed source JavaScript Web mapping libraries, as well as taking into consideration how to incorporate server-side mapping services and APIs. - -The proposed extension would create a standard `` widget that contains controls in a user agent shadow root, (similar to `