jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-httpapi-link-template

Commentary: " interpolate " feels very odd . Other choices would be " expanding " or " substituting " . I am not picky about the exact choice , but the current terminology seems odd . 
 The URI Template RFC uses ' expand ' , so that seems most appropriate .
indicates that a resource with the relation type
"https://example.org/rel/user" can be found by interpolating the
"username" variable into the template given.
indicates that a resource with the relation type
"https://example.org/rel/user" can be found by expanding the
"username" variable into the template given.
indicates that a resource with the relation type
"https://example.org/rel/widget" can be found by interpolating the
"https://example.org/vars/widget_id" variable into the template
given.
indicates that a resource with the relation type
"https://example.org/rel/widget" can be found by expanding the
"https://example.org/vars/widget_id" variable into the template
given.
Draft: draft-ietf-httpapi-link-template

Commentary: Has there been any consideration of allowing a URI Template for the parameter ? A particular use case would be for a collection resource that includes links from each item in the collection . If the media type supports fragments , then the item link could be templatized to point from specific locations in the representation . If we had a collection of books represented as an object with an array , and the instance media type allowed JSON Pointers : As an example of links between the full book resource and another resource , so as not to have to fetch the entire book resource if it is not needed , an author link template could be something like this ( ignoring the likelihood of multiple authors ): I was looking at this I - D in comparison to the ( currently tabled )     project , and I think that anchor templates are the most notable relevant    feature that is not present here . I would love to be able to use a revived    as a bridge between a link - template header field and JSON - compatible data .
Here, the link to the author for a particular book in a list of books
can be found by following the link template.
Draft: draft-ietf-httpapi-link-template

Commentary: Emerging best practice is to use for new headers , so that parsing is well - defined . Arguments for sticking with a -like syntax : Consistence with ( IMO a very poor justification ) Reuse of parsers / other software ( it 's not well - defined , tho ) ? ? ? 
 We could also talk about creating a SF version of ( maybe ? ) . 
 Matching SF and headers would be appealing . 
 In the meantime ( or maybe before ;) --
This document uses the Augmented BNF defined in HTTP to specify valid
protocol elements.  Additionally, it uses the modified "parameter"
rule from RFC5987 and the "URI-Template" rule from URI-TEMPLATE.
The Link-Template header field provides a means for serialising one
or more links into HTTP message metadata.  It is semantically
equivalent to the Link header field defined in WEB-LINKING, except
that it uses URI Templates URI-TEMPLATE to convey the structure of
links.
This specification uses the following terms from STRUCTURED-FIELDS:
List, String, Parameter.
The Link-Template header field is a Structured Field STRUCTURED-
FIELDS that serializes one or more links into HTTP message metadata.
It is semantically equivalent to the Link header field defined in
WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey
the structure of links.
Its value is a List of Strings.  Each String is a URI Template, and
Parameters on it carry associated metadata.
Parameters on a templated-link have identical semantics to those of a
Link header field.  This includes (but is not limited to) the use of
the "rel" parameter to convey the relation type, the "anchor"
parameter to modify the context IRI, and so on.
Likewise, the requirements for parameters on templated-links are the
same as those for a Link header field; in particular, the "rel"
parameter MUST NOT appear more than once, and if it does, the
templated-link MUST be ignored by parsers.
Parameters on a templated-link have identical semantics to those of a
Link header field.  This includes (but is not limited to) the use of
the "rel" parameter to convey the relation type, the "anchor"
parameter to modify the context IRI, and so on.  Parameter values
MUST be Strings.
Likewise, the requirements for parameters on templated-links are the
same as those for a Link header field.