Hyper-schema: promoting progressive disclosure

[awwright]

Links on the Web follow the concept of progressive disclosure: The links that are shown are only the ones relevant to the resource they appear on. If a resource has been locked for editing, it does not make sense to provide a rel="edit-form" link.

We should examine how JSON Hyper-schema inhibits, if at all, progressive disclosure on the Web.

[Relequestual]

Isn't this the opposite of the readOnly property at 4.4 of JSON Hyper-schema?
OR is readOnly only for object level, and you're proposing field based level?

As an aside, I note at http://json-schema.org/latest/json-schema-hypermedia.html, the changelog for draft 4 says that readOnly was removed, but yet it is in that document...

[awwright]

readOnly is something entirely different, I think... It says the value of a property is managed exclusively by the server/authority who owns the document, so it doesn't make sense to change that property (changes will be overridden or error).

This issue is talking about the issue of how do we not generate link relations that don't apply to the document. You shouldn't generate an "edit-form" link if the document isn't editable. You shouldn't provide a signout link if you're not signed in. And so on.

[Relequestual]

Interesting. Fair enough.

I think some real scoping of what Hyper-Schema can and should do is probably needed to better tease out requirements. That may just be because I don't understand it very well and don't see how it can be practically used, and haven't looked at any libraries that take advantage of it.

[handrews]

readOnly is something entirely different, I think... It says the value of a property is managed exclusively by the server/authority who owns the document, so it doesn't make sense to change that property (changes will be overridden or error).

I still have the use (or more likely $use) proposal for overriding usage-related fields at point of use to file (from that thread about re-use on the google group). In addition to overriding annotation fields, it would apply to fields like readOnly that are about how a schema is used without affecting structural validation. In particular, it clarifies the situation of two conflicting values of readOnly.

That proposal's almost ready to go, just the (wonderful) explosion of issue discussions here has distracted me from finishing it up.

[handrews]

Filed #98 about $use as mentioned in the previous comment.

[awwright]

Looking at this again, it appears #49 is what I was thinking of all along.

I'm trying to remember why I filed this... Maybe I should put a little note in hyper-schema to remind everyone this is a concern