diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml
index d48264a2..ec954021 100644
--- a/jsonschema-hyperschema.xml
+++ b/jsonschema-hyperschema.xml
@@ -8,7 +8,9 @@
+
+
]>
@@ -358,7 +360,15 @@
URI Template variables in "href" resolve from
- server-supplied instance data by default.
+ server-supplied instance data by default. This data is drawn from the
+ sub-instance that validated against the schema containing the LDO.
+
+
+ "hrefPointers" allows adjusting
+ the location from which instance data is resolved on a per-variable
+ basis.
+
+ "hrefSchema" allows a link to specify
a schema for resolving template variables from client-supplied data.
Regular JSON Schema validation features can be used to require resolution
@@ -528,7 +538,7 @@
-
+
Sometimes, the appropriate values will not be available.
For example, the template might specify the use of object properties,
@@ -548,6 +558,116 @@
+
+
+ The value of the "hrefPointers" link description property MUST be
+ an object. Each property value in the object MUST be a valid
+ JSON Pointer, or a valid
+ Relative JSON Pointer
+ which is evaluated relative to the position in the instance from which
+ "href" template variable resolution would
+ normally begin.
+
+
+ For each property name in the object that matches a variable name in the
+ "href" URI Template, the value of that property adjusts the starting position
+ of variable resolution for that variable. Properties which do not match
+ "href" template variable names MUST be ignored.
+
+
+
+ Recall that a Relative JSON Pointer begins with a number indicating
+ how many levels up to move before applying the remainder of the pointer,
+ if any, in the same manner as a regular JSON Pointer. Consider the
+ following schema for n-ary tree nodes, where a node is identified by
+ its own id as well as the tree's root node id, and links are given for
+ the IANA-registered "self" and "up" link relation types.
+
+
+
+
+
+
+ In "self" link, the context node's id resolves with the standard process and
+ therefore does not appear in "hrefPointers". In both "self" and "up" links,
+ the root id is located using an absolute JSON Pointer. Finally, in "up" link,
+ the parent node uses a Relative JSON Pointer, going up two levels (one level up
+ is the array of children, two levels up is the whole parent node), and then
+ looking at the "id" field from that point.
+
+
+
+ Given the following instance:
+
+
+
+
+
+
+ For each node (as identified by JSON Pointers), we get these "self" links:
+
+ /trees/0/nodes/0
+ /trees/0/nodes/1
+ /trees/0/nodes/2
+ /trees/0/nodes/3
+
+
+
+ and these "up" links:
+
+ /trees/0/nodes/0
+ /trees/0/nodes/1
+ /trees/0/nodes/2
+
+
+
+ For the root node, the relative pointer for the parent doesn't point
+ to anything. As noted under
+ missing values, such a link should
+ simply be ignored.
+
+ GitHub issue #49 tracks the question of distinguishing this situation
+ of a missing required variable (common in path components) from
+ missing optional variables (common in query string parameters).
+
+
+
+
The value of the "hrefSchema" link description property MUST be
@@ -1190,6 +1310,8 @@ GET /foo/
&rfc3986;
&rfc6570;
+ &rfc6906;
+ &I-D.luff-relative-json-pointer;
&I-D.reschke-http-jfv;
diff --git a/links.json b/links.json
index 76be45b1..286309e1 100644
--- a/links.json
+++ b/links.json
@@ -9,6 +9,16 @@
"type": "string",
"format": "uri-template"
},
+ "hrefPointers": {
+ "type": "object",
+ "additionalProperties": {
+ "type": "string",
+ "anyOf": [
+ { "format": "json-pointer" },
+ { "pattern": "^[0-9]" }
+ ]
+ }
+ },
"hrefSchema": {
"allOf": [
{ "$ref": "http://json-schema.org/draft-06/hyper-schema#" }