The URL template specified by link@tref needs to be reviewed

[prushforth]

A quick review of the spec by a parser expert (@zcorpan) indicates that URL templates have been attempted and failed in the Web platform previously. I am looking for links that document that attempt, so that might inform how we can work around this issue, if possible. If impossible we will have to pave a different cowpath (URL templates are currently used in web mapping libraries).

One of Simon's comments is that the { } characters are legal URL standard characters, and so it wouldn't be possible to distinguish template variables from non-variable reference uses of those characters.

I suggested that the user could pct encode the template string before inserting template variable references and placing the resulting string in the tref attribute, but Simon suggested that would break servers that were expecting non pct-encoded { and } in their content.

So maybe there would have to be a two-stage process where the string would have template variables replaced and then be pct-decoded so as to return { and } that had been pct encoded to their original form. Having done these two steps, the link would then become an href with a property value reflecting the process results, which could then be dereferenced.

Any links to the attempts to implement URL templates in the platform would be appreciated. I posted about them on WICG, but I was reluctant to bring up Web maps as the use case, because by themselves they don't solve Web maps, just a little (potentially important) bit of the problem.

[zcorpan]

url template was proposed for the initial design of <img srcset> but not used because authors want more flexibility in how to name their image files (and with CDNs, they may have no control over the final URL).

https://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html https://krijnhoetmer.nl/irc-logs/whatwg/20120509

URL templates was proposed for Web Forms 2.0 but wasn't added primarily due to lack of use cases, AFAICT

https://lists.w3.org/Archives/Public/uri/2008Oct/0001.html

Well, that's what I can find right now. Not so much support for my claim that it didn't work out due to { (or any other character) facing compat problems with existing URLs where they are used and sent unescaped (in some parts of the URL), but I still think that is a real risk for URL templates.

[prushforth]

@zcorpan Thanks for digging those up, Simon. Reviewing now.

[prushforth]

not used because authors want more flexibility in how to name their image files (and with CDNs, they may have no control over the final URL)

Web mapping APIs commonly require the coordinate location information that can be flexibly passed by template-based access. This is one of the major cow paths that has been established by the Web mapping server community. I believe that the <input name="..."> mechanism of identifying template variables allows a great deal of flexibility in mapping client event semantics to server API semantics without forcing naming from one onto the other. So that's (<input name="...">) a Web platform pattern that can be used to good effect to match a Web map service pattern: win-win IMHO.

https://krijnhoetmer.nl/irc-logs/whatwg/20120509

In that discussion there seems to be a bias towards % variable names vs. using https://tools.ietf.org/html/rfc6570 { and }. FWIW I think the RFC goes way overboard but the common usage of template variables that I linked to in the OP is what would work, possibly better than the % variables, because you could say that the string used in tref would have to be pct encoded before adding variable references and then pct decoded after prior to interpretation as a URL per the URL standard.

Web Forms 2.0 but wasn't added primarily due to lack of use cases, AFAICT

Yes, it seems that the use case that was proposed by the Restlet fellow is similar to what I proposed on the WICG in the OP. I think the use case here (Web maps) is pretty compelling, but yes, simple URL templates are trivially done from script in the Web mapping libraries I linked to. What we're trying to do is pave that cow path, and I don't know if the platform can learn from what Web devs have wrought, but if it can this might be a good example.

compat problems with existing URLs where they are used and sent unescaped (in some parts of the URL), but I still think that is a real risk for URL templates.

OK, I will keep looking at the problem.

I think badly formed URL templates can give rise to a lot of mapping server nuisance traffic, that is a real risk. That traffic is today generated by script. That does seem to be part of the Web mapping paradigm. I think servers can help avoid some of the nuisance traffic they see by transmitting <input>s that minimize the errors, for example by setting min/max according to the data they can serve etc. I believe that if we can set up the incentives correctly (in our design), the servers will emit markup that optimizes the traffic and minimizes the nuisance.

[bkardell]

It seems to me that there are a bunch of challenges with template URLs here...

If you're looking at them very 'generally' in a markup it seems hard to explain their value as any of them would require some dynamic context and mechanism with which to signal when to bind them, at which point they are suddenly serializable by just standard HTML and then also (or as part of it) for that thing to indicate that it should submit.

Alternatively, you could even (I think) create lots of potential submits and just have a bunch of formactions, then you're mostly managing which one to activate, that leaves a lot declarative, but I don't think this is practical for maps use cases.

It feels to me like you are going to always specify some kind of 'controller' here for that as you need (probably) to plug in more arbitrary things (again, looking at it more generally) and once in js, you have template literals which are pretty good for this (I think?) which probably means we wouldn't change URL itself to support that either.

Seems tough to unwind at this level - but less so at a slightly lower one perhaps?

[prushforth]

@bkardell thanks for dropping by.

dynamic context and mechanism with which to signal when to bind them, at which point they are suddenly serializable by just standard HTML and then also (or as part of it) for that thing to indicate that it should submit.

I'm not quite sure what you mean by this. Are you referring to using URL templates in a non-map context? If so, I possibly agree, to the extent that I haven't come across too many other situations, except perhaps forms, in which they might be useful. I question that everything has to have multiple 'clients' though. Nice to have, maybe.

formactions

In maps, the layer extent "binds" to the dimensions of the map viewport, so I guess the map is the 'controller'. As the user pans, zooms, initializes or resizes the viewport, the map generates events that are demanded by the inputs in the extent.

template literals which are pretty good for this (I think?)

I don't use template literals (I don't think so at least, I'm just using a Leaflet method for variable substitution so haven't looked at what it's doing recently).

we wouldn't change URL itself to support that either

I'm not suggesting any change to URL, I don't believe. Just a method of creating an input string that should be parsed as a URL.

Seems tough to unwind at this level - but less so at a slightly lower one perhaps?

I'm not 100% sure I've understood the points you've raised, but thanks for thinking about this.

[bkardell]

I'm not quite sure what you mean by this. Are you referring to using URL templates in a non-map context?

Yeah I suppose my comments were largely along the wicg proposal, or where can you fit them into the platform generally.. in part because I feel like this was a good effort to break down more discrete needs/general asks of the platform.. Just explaining why I think this particular one is challenging. It's hard to see where to fit it well (to me, perhaps others are more creative)

As the user pans, zooms, initializes or resizes the viewport, the map generates events that are demanded by the inputs in the extent.

I feel like the first part of this sentence is the more critical/common need (and maybe in some ways simpler) I guess was my larger point. That they update inputs which then bind into urls at some point seems to me perhaps a second thing to think about.. If that makes sense? It's entirely plausible that I see this incorrectly though, and I don't want to distract this issue more than I have already.