-
Notifications
You must be signed in to change notification settings - Fork 71
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
Properties title #77
base: master
Are you sure you want to change the base?
Properties title #77
Conversation
I don't see how this is backwards compatible. A client has to check if a property is an object, but existing clients won't. |
@apsoto can you tell me what part of the existing specification or JSON schema specifically disallows using non-strings as values? As far as I know, declaring something as |
There's isn't anything that disallows non-string values, but existing servers where there are entities with objects as properties this is a breaking change because there was no If there was a way for clients/servers to negotiate compatible spec versions then this would be compatible. |
I understand. This probably means that |
The purpose of the We haven't figured out how to advertise "extensions" yet, but having a |
@kevinswiber what about media type parameters? Like with |
@kevinswiber But wouldn't anything apart from a simple type like an object be actually an entity? I think as soon as you got a nested structure you can and should give it a name. |
@martinotten I've found it useful to have the flexibility to put an array or other simple objects in properties in some cases. If I had to turn those into entities it would be rather burdensome. |
I've explore this before on how to annotate data in data that maybe nested—and it's quite difficult. Here are the options I've found. Provide annotations in a separate flat objectThis would use a special object for defining semantics apart from the actual values, then optionally map those to the properties in the object. I tried this approach here though it's old and wildly incomplete :)
This is a little more backwards compatible. Embed annotations with a reserved propertyAllow for metadata around properties to be added into a reserved object. Whereas the example above was flat and probably done at the root of an entity, this would be nested inside the property object. JSON-LD does some of this with it's prefixed properties and
We also put together a similar proposal for a more complex implementation for annotating JSON in what we called embedded annotations. This is backwards compatible only if clients are instructed to ignore properties it does not know about AND they haven't used Allow for expanding valuesThis is the route this PR takes. The downsides are that you you end up with a magical recursion for handling annotations, and it gets very complicated as you get more nesting in the Full on XMLDon't do this with Siren, just use XML :) Basically, if you wanted to, you mimic how XML works. Again, don't do this, however, the current PR is a baby step toward this direction.
|
@apsoto Why is that bothersome? This entity wouldn't need its own URI, would it? So moving it to an entity would just mean that you express it in a different structure. It would also have the advantage that you would also define a class you can reuse in another context, like an address. |
WRT turning complex property structures into entities is burdensome in that it requires more coding. Likely it's a side effect of the way we serialize our Siren responses. Adding properties are simple one line changes. Adding new entities are typically whole new Classes (as in Java or Ruby classes) Also, I personally do in fact model entities as an uniquely addressable object (URI). If an entity doesn't have a URI then it's a design smell that it maybe shouldn't really be an entity. |
This introduces human-readable titles for entity properties in a backwards-compatible way. Among other advantages, properties with objects as values would enable clients to display labels translated to the HTTP
Accept-Language
.