From 444748e1e06de56d0e7cbfd25802c68d9710a400 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 25 Aug 2017 01:54:23 -0700 Subject: [PATCH 1/5] Explain applying hyper-schema based on validation ...before jumping into when you SHOULD NOT apply hyper-schema. Reading over this for the first time in a few months, it was a little abrupt. --- jsonschema-hyperschema.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index 1840184b..c112d532 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -211,6 +211,10 @@
+ + Hyper-schema keywords can be applied when the instance is valid against + the schema that includes those keywords. + Hyper-schemas MUST NOT be applied to an instance if the instance fails to validate against the validation keywords within or containing the hyper-schema. From a7c50d61e637c504f41e881481cc4e77f2b47d80 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 25 Aug 2017 01:58:33 -0700 Subject: [PATCH 2/5] Phrase as a requirement. For some reason I wrote this as an assertion rather than a requirement in specification language. Fixed. --- jsonschema-hyperschema.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index c112d532..3c0e8626 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -478,8 +478,8 @@ inherent relation to the target resource's representation The three ways to use client-supplied data are each addressed by a separate - schema keyword within the link description object. Link operations - ignore schemas that are not relevant to their semantics. + schema keyword within the link description object. When performing operations, + clients SHOULD ignore schemas that are not relevant to their semantics. Link Description Objects do not directly indicate what operations, such From d9304def4d7c365cc8c013fb3dad899de73635e5 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 28 Aug 2017 23:11:59 -0700 Subject: [PATCH 3/5] Define operations before discussing them. In retrospect, this section ended up being rather confusing since it assumed the reader understood the idea of an operation as opposed to a link. State that concept clearly. --- jsonschema-hyperschema.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index 3c0e8626..a1c1eae2 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -468,6 +468,10 @@ hint may be added in a future draft (see issue #73 in the GitHub repository). + + An operation is a specific use of a link described by an LDO, after any + template variables have been resolved. + There are several ways that a client can use data with a link: From ccebf95fed64be784d8cfe0cda7fa733e29f73ef Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 30 Aug 2017 09:38:47 -0700 Subject: [PATCH 4/5] Further clarify $id base URI determination. "object as a whole" could be read to mean the entire schema document, ignoring any intervening $id keywords. This clarifies that that is not the case. --- jsonschema-core.xml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 910cf3f0..e2754d77 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -431,10 +431,12 @@
- The "$id" keyword defines a URI for the schema, - and the base URI that other URI references within the schema are resolved against. - The "$id" keyword itself is resolved against the base URI that the object as a - whole appears in. + The "$id" keyword defines a URI for the schema, and the base URI that + other URI references within the schema are resolved against. + A subschema's "$id" is resolved against the base URI of its parent schema. + If no parent sets an explicit base with "$id", the base URI is that of the + entire document, as determined per + RFC 3986 section 5. If present, the value for this keyword MUST be a string, and MUST represent a From ec5c9cd3ee6dc145cfc787f0b9183ab5a2092948 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 30 Aug 2017 09:42:50 -0700 Subject: [PATCH 5/5] Clarify fragment-only vs all URIs Fix this wording to make it more clear that this requirement is about fragment-only URI references, and that other sorts of URI references are not constrained by this paragraph. --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e2754d77..b58771e7 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -470,7 +470,7 @@ Pointer references are updated. - The effect of defining a URI fragment "$id" that neither + The effect of defining a fragment-only "$id" URI reference that neither matches the above requirements nor is a valid JSON pointer is not defined.