-
Notifications
You must be signed in to change notification settings - Fork 890
Explain complex attributes and linking from within #417
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
b414fae
to
98276d7
Compare
Adding for 1.0 final review. |
I'm 👍 to finding a way to explicitly allow nested links for future consideration, but I think it is premature to have examples of this usage in the spec. What about simply reserving the |
Actually, reserving any reserved keywords at any level of nesting. |
Yes, this is sufficient I believe. |
"Any reserved keywords" is not well-defined. Would this mean |
Yes - any keywords reserved in a resource object. |
@bintoro I definitely don't want to include an example here. We are simply reserving the keys, without making a statement about their usage. |
Updated! |
👍 |
@bintoro please rebase |
Rebased. By the way, if there's a short answer to why linking from complex attributes is so contentious, I'd love to hear it! |
Explain complex attributes and linking from within
For my part, it's lack of experience with implementations doing this in the wild. It could well be that the resulting impact is minor, but I feel it bears more consideration before we explicitly support this. I'd love to continue the discussion post 1.0, though! I am out of town for most of March but when I return I am going to create a test suite using a reference database that any implementor can use to validate compliance with the spec. Once that is in place I think it will be much easier for us to reason about additions like this--we can temporarily add them to the test suite and reference database to see the real world implications. |
@bintoro thanks for rebasing!
The possibility of nested, n-level deep links that must be maintained and accessed independent of the containing object (ie. resource) adds a large burden of complexity to implementations. I would prefer that this be implemented as an extension first (and perhaps exclusively) as a proof of concept.
Very excited for this @tkellen! |
Has linking from complex attributes made any headway since this discussion? |
Submitting for last-minute review because this cannot happen post-1.0 in the form proposed here due to the reserved-key issue.
Resolves: #289, #383
The representation of outbound links follows my suggestion in this comment that was later vetted against alternative approaches in #383.
(cc @ethanresnick)