-
-
Notifications
You must be signed in to change notification settings - Fork 309
Rework the descriptions of using data with links #293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
jsonschema-hyperschema.xml
Outdated
In JSON Hyper-Schema, <xref target="targetSchema">"targetSchema"</xref> | ||
supplies a non-authoritative description of the target resource's representation. | ||
A client can use "targetSchema" to structure input for replacing or | ||
modifying the representation. Alternatively, if "targetScheam" is absent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: "targetScheam" => "targetSchema"
jsonschema-hyperschema.xml
Outdated
<t> | ||
The following properties also apply to Link Description Objects, and provide functionality analogous to <xref target="W3C.CR-html5-20140731">HTML forms</xref>, by providing a means for making a request with client- or user-selected information. | ||
If present, this property indicates the media type format the | ||
client should use to for the request payload described by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo ?
@jdesrosiers thanks for catching those! Should be fixed now. |
@handrews Thanks, you read my mind |
This replaces the rather lengthy discussion of hrefSchema with a more concise and complete description of all of the ways to use data with links. This should now serve to set the context for the various ways to use LDOs.
should be inferred primarily from link <xref target="rel">relation types</xref> | ||
and URI schemes. Note, however, that a resource may always decline an operation at | ||
runtime, for instance due to application state that controls the operation's | ||
availability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like we're comparing the LDO against something (HTML forms?), but there's no indication of what that is.
I would move this paragraph down one so we lead with what it does, not with what it doesn't do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, fixed.
jsonschema-hyperschema.xml
Outdated
There are several ways that a client can use data can with a link: | ||
<list> | ||
<t> URI Template variables resolved from server-supplied instance data </t> | ||
<t> URI Template variables resolved from client data </t> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two lines might be too easy to conflate. I would say something like
- Plain links, where all variables in the URI Template (if any) are filled from instance data
- Link templates, where the URI Template contains variables that can be filled in by a users or agent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your phrasing is not clear to me, and I don't have any intuition for "Plain links" vs "Link templates", especially because your plain links obviously involve template variables.
The distinction is not across the template, it's that there are different ways to use template variables, which might appear in any combination in a template.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see. I suppose that works.
What about "URI Template variables resolved from user input"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about "URI Template variables resolved from user input"?
This is a good point: I've avoided "user input" in favor of "client data" because of situations (like autonomous Things in the Internet of Things sense) where there is no direct user input, but there is data coming through the client from somewhere.
So I don't want to make it sound like there has to be an actual user interaction involved, but I do want the purpose to be clear.
client input? user-agent input?
Yeah I see exactly what you mean... I figure most people know a "user" can
be automated.
Technically, it's always an agent making the request and filling in the
variables, how about "agent"? Iirc that's how HTML deals with it.
…On Apr 7, 2017 11:07 PM, "Henry Andrews" ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In jsonschema-hyperschema.xml
<#293 (comment)>
:
> </t>
<t>
- See the individual keyword descriptions below for details related to each of these cases.
+ There are several ways that a client can use data can with a link:
+ <list>
+ <t> URI Template variables resolved from server-supplied instance data </t>
+ <t> URI Template variables resolved from client data </t>
What about "URI Template variables resolved from user input"?
This is a good point: I've avoided "user input" in favor of "client data"
because of situations (like autonomous Things in the Internet of Things
sense) where there is no direct user input, but there is data coming
through the client from somewhere.
So I don't want to make it sound like there has to be an actual user
interaction involved, but I do want the purpose to be clear.
client input? user-agent input?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#293 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAatDRLuRWHhwHxEX5wGMibyTk264mq7ks5rtyQKgaJpZM4MwDxy>
.
|
@awwright "agent" works for me, and as you note there is precedent. I'll look through the spec and try to make sure the language is consistent as I know I have "client data" in some places, and "external data" in others. And probably still "user input" somewhere. I'll update the PR tomorrow. |
Instead of "user input", "client data", and "external data".
@awwright the latest commit changes everything to "user agent data". I looked through the HTML5 spec and RFC 7231 and both consistently user "user agent" (never "agent" on its own). So that seems the safest option. Previously, I'd used several different phrases all over the place, so I went ahead and cleaned it all up. If you want look at this part on its own the commit diff is: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even better! Yeah, "user agent" is the right call here it seems
@awwright Yay! This was the last PR (aside from the meta-schema URI which I assume you'll either merge when you do the release or do it on your own, I don't care which). I think you are clear to publish draft-wright-json-schema-*-01! |
IGNORE the first commit, it is from PR #292
Review this commit here: af5ef3a
This replaces the rather lengthy discussion of hrefSchema
with a more concise and complete description of all of the
ways to use data with links. This should now serve to set
the context for the various ways to use LDOs.