Repository navigation
Consider making MapML an extension to HTML #70
Description
A MapML document is a [MicroXML] document. As such, it MUST have a single root element named . It MUST NOT have a DOCTYPE declaration; attributes named 'xmlns' and names containing a colon character ':' (U+003A) are not permitted. Other restrictions relative to XML syntax are enumerated in [MicroXML].
Meanwhile, in the map element proposal, for the layer element, says:
If the src attribute is present: Empty. If no src attribute is present: Metadata content describing nested Map Markup Language content
MapML can't be MicroXML and also be embeddable in HTML (without significantly changing the HTML parser).
MicroXML implies that MapML elements are in no namespace. Apart from RSS, languages that browsers support use namespaces.
Changing the HTML parser to support a new class of foreign content seems unlikely to happen for MapML, or even for anything. Even minor changes are usually met with resistance from implementers, due to security concerns.
With https://github.com/prushforth/htmlparser and https://www.w3.org/community/maps4html/2019/12/09/the-design-of-mapml/ , I've understood that the intent is to change MapML to be more "like HTML", instead of MicroXML.
If so, that should be formalized in the MapML spec. Further, if the intent is to be able to embed MapML inline in HTML documents, I think the best way to do that is to make all MapML elements be HTML elements directly, and MapML documents be HTML documents. (XML serialization is still possible, like with HTML.)
The implications would be:
- Maybe use
text/mapml+htmlas the MIME type, if MapML needs its own MIME type. Otherwise usetext/html. - Doctype should be
<!doctype html>(or maybe allow omitting it for new MIME type) - Root element should be
html, containingheadandbody. - Interfaces for elements should be
HTMLElement, orHTMLExtentElement : HTMLElementetc. - Audit each MapML element if it can reuse an existing HTML element name:
head,title,base,meta: these don't seem to have MapML-specific processing. Remove from the MapML spec.link: ?extent: if this is intended to reuse form submission, maybe useforminstead? (I'm not sure why MapML needs form submission?)input: this doesn't seem to be a widget that expects user input; suggest minting a new element name.datalist,label,select,option: ?image: the HTML parser treats<image>as a macro and changes it to<img>. New element name?feature,properties: don't clash with anything, but are a bit genericgeometry: doesn't clash, though this seems to be yet another way to represent 2d geometric shapes on the web. We have SVG,<area>, canvas 2dcontext API, Geometry APIs. This seems most like<area>, except it's only geometry data without hyperlink.coordinates: why is this an element, and not an attribute ofgeometry?
Activity
prushforth commentedon Jul 3, 2020
I don't have enough experience in this domain to understand the security concerns, but it seems that some level of change must be ongoing as the vocabulary changes. I hope that minor changes can be accomplished for maps as a high-level feature in a single (group of) changes.
Yes, the intent has always been to achieve maximum compatibility with HTML. My understanding of this compatibility has evolved over the course of this project, to the degree that I now believe MapML may be a good marketing term (YMMV), but it should actually be part of HTML, so that it comes with a DOM API that allows it to be programmed by Web devs, when included inline in HTML. I appreciate that this may cause confusion to a reader such as yourself, and I'll work towards removing that confusion for developers who follow you.
Agreed.
OK. We haven't registered a MIME type yet. We will have to update the spec and the polyfill, as well as the servers (GeoServer, MapServer) that will support maps in HTML. I believe the use of
text/mapml+htmlmay involve a more elaborate registration. Unless I'm mistaken, which is my specialty, actually,+htmlsuffix will need to be registered first, and may be starting a new suffix, akin to+jsonetc.I believe it does require it's own MIME type, so that browsers know what to do with it when the context isn't fetching a layer in a map. i.e. it might be possible to synthesize a surrounding html, head, body, map and layer as it does with an image file.
Even when the context is fetching a layer within a map, it might even be useful to render text/html even on the map, if the rendering mode was by coordinate-specific means vs normal html rendering. We should discuss this more, but I think it could be a valuable general situation / use case.
OK, I worry a bit that we are relying too much on the MIME type if we don't have a <!doctype mapml> or root mapml element, but maybe that is misplaced concern, as I don't fully understand what these <!doctype html> and root html are used for.
Yes. Again I'm a little fuzzy about the implication of not having a doctype and relying solely on the MIME type.
Yes. In HTML, I believe html, head and body are optional, supplied by the parser if not present.
Does this need to be specified in the MapML specification/proposal? I think yes, but not sure.
Yes, agreed.
OK. What about specifying the meta values that we need? Where should those go?
We have a few requirements around link, some of which seem to fit in with how link is used generally, others which may be more surprising. Lots to discuss, I guess :-)
We started out using
extentlike a form, but the submission model of aformis not similar enough to that of maps, so we ended up removing / deprecating theextent@actionmethod of content retrieval, because template-based (link@tref) content retrieval paves the cowpath of how Web maps work today in script libraries. I will ensure thatextent@actionis completely removed from the spec, as I think it was an early mistake.Someday, not today, it would be cool to be able to use the map as an input method for forms, enabling declarative geospatial content creation, e.g.
<input type=location subtype=linestring ...>Was trying to re-use related stuff from HTML. The user input is gestures for zoom/pan events (move, moveend) however I can see why you think it should be something else.
These probably require a demo to show what they are proposed to do for maps. They are mostly used to populate the layer control entry for the layer with values that control the requests that are made to a map or tile server, for example to allow the user to view the map layer at a particular date, or elevation, or for example to view highways only from a roads layer. Maybe when you see how these are used to control the content of the map, using
inputwon't seem so odd?Maybe
img? Map images aren't that different from regular images, and instead of extending the set of elements we apply the same re-use of existing semantics but update the rendering model?These come from GeoJSON, but I was thinking recently that
locationinstead offeaturemight be more consistent with theinput@type=location. The Simple Features model is a very solid standard, and it's on this model that GeoJSON, KML, GML, Shapefiles and pretty much every spatial database format is based these days. So that's where I got the word feature from. I think it's based on a standard object-property model or something.This is a pretty big discussion on its own, I think. The reason attributes aren't adequate for geometries is because we need to be able to use CSS selectors on whole or part geometries or even parts of geometry parts, in order to a) style them differently/appropriately than the rest of the geometry and b) make hyperlinks out of their constituent parts or parts of their constituent parts.
We really want to use CSS and not invent whole new layers of abstraction; I think we want to work with the SVG community to work on common requirements for CSS. Sometimes SVG is perfectly adequate for map annotations / graphics / legends, but generally is difficult to use for map features. SVG, while great, and while it may allow us to simulate / polyfill spatial feature geometries by allowing us to generate
<path> (etc) elements out of the parts of the geometries in order to style or link them separately, is not generally used to represent map features because it's too slow on the one hand and not feature specific enough on the other hand. Linking and styling are related in that they (sometimes) require within-geometry markup and I believe the killer feature of the web is linking, so we want to re-use that feature between map layers and between map layers and html documents/ Web apps.Attributes (like those used by svg paths) can have their own grammar, but they can't contain markup. We need to include markup in feature geometries for the reasons cited above.
zcorpan commentedon Jul 3, 2020
See whatwg/html#2253 (comment)
However, new elements can be added to HTML without changing the parser, if the parsing behavior of unknown elements is OK (which is, parse like
<span>; this is also how all custom elements are parsed). This should be OK for MapML I think. Onlytilehas an empty content model and could be parsed as a void element, but it doesn't seem critical and maybe we'd want to put something intileelements in the future.zcorpan commentedon Jul 3, 2020
OK cool. I suggest filing an issue at whatwg/html so they are aware of this proposed extension to HTML.
zcorpan commentedon Jul 3, 2020
Looks like I was mistaken here. :-) I thought +foo was a convention, and +xml was the only one with special handling, but now I found
https://tools.ietf.org/html/rfc6839
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
I undecided right now if +html really makes sense. Maybe it doesn't and text/mapml is right.
OK, yeah. This would need to be defined in HTML analogous to https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-media
OK.
prushforth commentedon Jul 3, 2020
Funny you should mention that, as we've been developing static tile layer code lately. We imagine that it might be useful to have content in a tile, for example > 1
imgor other set of elements, includingsvgand whatnot. The placement and zoom/pan animation would be done by the browser so it would be pretty simple to pile content into a tile.prushforth commentedon Jul 3, 2020
Is that jumping the gun? Anyway I guess I jumped it some time ago, but maybe it's time to bring some new energy to the process.
zcorpan commentedon Jul 3, 2020
No it seems better to give the HTML folks a heads up about proposals that extend HTML early. If this was the plan all along, it's not early anymore, but better now than later. :)
zcorpan commentedon Jul 3, 2020
Filed #72
zcorpan commentedon Jul 3, 2020
Yes. (Filed #73)
zcorpan commentedon Jul 3, 2020
What are those? I don't see meta names specified.
But you can specify those in MapML -- only the name and the processing associated with it. See https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names for the currently standardized meta names in HTML.
Malvoz commentedon Jul 4, 2020
The
zoomandtcrsvalues are mentioned in sections 4.1.4 Scale / Resolution / Zoom levels and 4.1.5 Extents respectively. Supposedly they'll need to be properly defined, I think that's the intent with issue #7.prushforth commentedon Jul 4, 2020
@zcorpan A question I have about processing a text/mapml response received from.a 'layer src' request is: how will HTML elements that aren't in the MapML vocabulary of HTML be rendered? We have to have a proposal for that if it's all to be handled with no change to the parser.
Malvoz commentedon Jul 14, 2020
There was a similar consideration for HTML Modules to use a
+htmlsuffix, while they concluded not to use such a suffix, nobody questioned its validity in response to this and the following comment, which at least indicates thattext/mapml+htmlwould be valid.prushforth commentedon Jan 25, 2021
@zcorpan wrote:
We've updated the MapML spec to say that MapML documents are in the xhtml namespace (xmlns="http://www.w3.org/1999/xhtml/"), and removed references to MicroXML. I've updated the demo service to serialize MapML documents into that namespace. We've also tested the polyfill to ensure that it supports the namespace version of MapML, and we've updated the GeoServer MapML Community Module to serialize MapML documents in the xhtml namespace.
Robert and I agreed we should have a community group discussion asap to help us decide what to put into this issue for the best possible response. Please vote for the meeting time.
prushforth commentedon Jan 27, 2021
Here are the meeting details. Add your comments below for discussion there, if applicable.
prushforth commentedon Mar 12, 2021
We've moved the xml vocabulary into the xhtml namespace. We opened the issue with WHATWG. Cleaning up and closing.