-
Notifications
You must be signed in to change notification settings - Fork 2
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
transclude mechanics #14
Comments
Transclude spec makes no assumptions on where exactly included content is inserted in the original content. For HTML content it may make sense inlining to happe, but if we are talking about JSON payload in an API's case, such decisions can be application and use-case specific. I don't think we should prescribe behavior. Likewise, multipart example is given as just an example of how multiple transclusions MAY be handled, using pre-existing approaches, but doesn't require this to be THE solution |
On 2018-01-15 15:39, Irakli Nadareishvili wrote:
Transclude spec makes no assumptions on where exactly included content
is inserted in the original content. For HTML content it may make sense
inlining to happe,
where would HTML even have such a feature?
but if we are talking about JSON payload in an API's
case, such decisions can be application and use-case specific. I don't
think we should prescribe behavior.
fair enough, as it probably is hard to say how this can happen
independent of the specifics of a media type. maybe then it would make
sense to make this more explicit and say that the mechanics of the
facility are unconstrained?
what i dislike about this is that this means that even for the same
media type different servers then can behave differently, which reduces
the utility for clients.
Likewise, multipart example is given as just an example of how multiple
transclusions MAY be handled, using pre-existing approaches, but doesn't
require this to be THE solution
again, explaining this and putting it in context then would help. as it
is now, the reader is left a bit wondering what exactly is part of the
spec, and what is part of the implementation specifics.
|
i may be a little bit confused by the wording and the current section 5. most of the wording in section 3 seems to imply that
transclude
links are resolved and embedded on the server side (see #13 for my general confusion about the preference name). that would mean that in such a response, there would be no indication that something was a link. it simply would appear as embedded content (whatever that means for a given media type).section 5 looks a bit as if the "transcluded" resources are actually sent as separate content in a multipart response and the client still has to do the actual link resolution, only that it doesn't have to request the entities? some clarification on the general mechanics of the proposed facility would help to make this more clear.
The text was updated successfully, but these errors were encountered: