"anchor" should probably be a URI Template

[handrews]

If your "self" link href is something like foos/{fooId}/bars/{barId} and you have another link for which you want to establish the containing "foo" as your context, you would need an anchor of foos/{fooId}.

Note that since anchor is resolved relative to base, which is a URI Template, you can already accomplish this by setting base to foos/{fooId}, your self link's href to bars/{barId}, and the other link's anchor to `` (empty string path component).

It seems incorrect to allow doing that through convoluted means instead of just allowing it directly.

I think we just want to add the same wording that is used for base:

The URI is computed from the provided URI template using the same process described for the "href" [href] property of a Link Description Object.

The one exception might be that I don't think that hrefSchema would apply to anchor, or to base when it is being used with anchor. I'm not aware of any system in which user input is solicited to establish the link's context.

Related (although can be filed separately if preferred): Should we change the two keywords that would then apply to all three URI templates from hrefPointers and hrefRequired to something like templatePointers and templateRequired? We just added those two for this draft so it's not like anyone was depending on the names. And we've tweaked a lot of names already for clarity.

If we did that, we would have:

• Resolving anchor and resolving base for use with anchor: Apply templatePointers and templateRequired

• Resolving href and resolving base for use with href: Apply templatePointers, templateRequired, and hrefSchema

[handrews]

Hmm... thinking this through some more:

• Re-using hrefPointers/templatePointers with anchor makes sense, as it is good design to use the same variable names to mean the same things in both, and therefore the pointers should point to the same place for both. And having unused entries in the object (meaning used with href but not with anchor, or the other way around) is harmless.
• Re-using hrefRequired/templateRequired is a little trickier, but I think it still works. It would need to be updated to specify that the requirement only applies if the variable is present in the URI Template being considered. This should probably be done anyway as it already gets used with both base and href, which are resolved separately. We are currently vague on that "resolved separately" thing, but as I work on the rewrite it's clear that it's important (you can only resolve href against base after both are resolved to URI References from URI Templates)
• hrefSchema definitely still should only apply to href (and base when it is being used with href).

[handrews]

I'm going to post PRs for this, with the understanding that the lack of opportunity for discussion here means they are more likely to be shot down. I'd rather get the PRs up for consideration and the clock ticking on the feedback period given our overall timeline.

[handrews]

Merged #419.