Skip to content

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

Merged
merged 3 commits into from
Apr 9, 2017

Conversation

handrews
Copy link
Contributor

@handrews handrews commented Mar 31, 2017

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.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: "targetScheam" => "targetSchema"

<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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo ?

@handrews
Copy link
Contributor Author

handrews commented Apr 1, 2017

@jdesrosiers thanks for catching those! Should be fixed now.

@handrews
Copy link
Contributor Author

handrews commented Apr 3, 2017

@awwright this and #292 are awaiting your approval, at which point I think we are good to go with draft-wright-json-schema*-01

@handrews
Copy link
Contributor Author

handrews commented Apr 4, 2017

@awwright this PR now only has the one commit- I've rebased it on top of the merged #292 and #296. Should be more clear to review now.

@awwright
Copy link
Member

awwright commented Apr 4, 2017

@handrews Thanks, you read my mind

@handrews handrews added this to the draft-next (draft-6) milestone Apr 5, 2017
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.
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, fixed.

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>
Copy link
Member

@awwright awwright Apr 7, 2017

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

Copy link
Contributor Author

@handrews handrews Apr 7, 2017

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.

Copy link
Member

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"?

Copy link
Contributor Author

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?

@awwright
Copy link
Member

awwright commented Apr 8, 2017 via email

@handrews
Copy link
Contributor Author

handrews commented Apr 8, 2017

@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".
@handrews
Copy link
Contributor Author

handrews commented Apr 8, 2017

@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:

6bf4061

Copy link
Member

@awwright awwright left a 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

@handrews handrews merged commit 1f9fd20 into json-schema-org:master Apr 9, 2017
@handrews
Copy link
Contributor Author

handrews commented Apr 9, 2017

@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!

@handrews handrews deleted the operations branch April 9, 2017 07:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants