-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
Framing #6
Comments
At the Barcelona Sprint we discussed this, and were leaning towards already changing the layout of the default RationaleThe basic idea was to move field data out of the top-level namespace / data structure into their own The aim here is not to already implement full JSON-LD framing and using e.g. Proposed FormatThe proposed format would look somewhat like this: {
"@id": "http://nohost/plone/front-page",
"@type": "Document",
"UID": "1f699ffa110e45afb1ba502f75f7ec33",
"fields": {
"title": "Welcome to Plone",
"description": "Congratulations! ...",
"...": ""
},
"parent": {
"@id": "http://nohost/plone",
"...": ""
},
"actions": {"@id": "http://nohost/plone/front-page/@actions/"},
"versions": {"@id": "http://nohost/plone/front-page/@versions/"},
"workflow": {"@id": "http://nohost/plone/front-page/@workflow/"}
} A basic mock of almost exactly that format has been implemented in the Open Questions
|
Just so I don't rip my hair out a second time: JSON-LD Framing Proof of ConceptWe start with a fully expanded document that contains everything inline: from pyld import jsonld
context = {
'@vocab': 'http://plone.org/vocab#',
'plone': 'http://plone.org/vocab#',
'fields': 'plone:fields',
'workflow': 'plone:workflow',
}
doc = {
'@context': context,
'@id': 'http://localhost/front-page',
'@type': 'Document',
'fields': {
'@id': 'http://localhost/front-page#fields',
'title': 'Front Page',
'description': None,
},
'actions': {
'@id': 'http://localhost/@actions',
'@type': 'ActionsInfo',
'actions': [
{
'@id': 'edit',
'category': '',
'title': 'Edit'
},
]
},
'workflow': {
'@id': 'http://localhost/@workflow',
'@type': 'WorkflowInfo',
'transitions':
{
'@id': 'http://localhost/@workflow/publish',
'title': 'Publish'
},
}
}
frame = {
'@context': context,
'workflow': {'@embed': False},
'actions': {'@embed': False},
}
framed = jsonld.frame(doc, frame)
compacted = jsonld.compact(framed, context) After compaction, this then results in this final document: {
'@context': context,
'@id': 'http://localhost/front-page',
'@type': 'Document',
'actions': {'@id': 'http://localhost/@actions'},
'workflow': {'@id': 'http://localhost/@workflow'},
'fields': {
'@id': 'http://localhost/front-page#fields',
'title': 'Front Page'
}
} A frame that inlines the actions would then look like this: frame = {
'@context': context,
'workflow': {'@embed': False},
'actions': {'@embed': True},
} resulting in {
'@context': context,
'@id': 'http://localhost/front-page',
'@type': 'Document',
'fields': fields,
'actions': {
'@id': 'http://localhost/@actions',
'@type': 'ActionsInfo',
'actions': [
{
'@id': 'edit',
'category': '',
'title': 'Edit'
},
]
},
'workflow': {'@id': 'http://localhost/@workflow'}
} References: As stated above, the goal isn't to implement this anytime soon, but it serves as proof that JSON-LD framing is the right tool for the job, we can use it to accomplish what we need, and we're not barking up the wrong tree (no pun intended). |
@tisto @buchi do any of you have any strong opinions on the two open questions above? Because if this still requires some substantial discussion / research, we might want to reconsider and not view it as a blocker for an alpha release. |
@lukasgraf I don't see framing as a blocker for an alpha release. Thanks for the detailed analysis/proposal. Will try to find time to reply asap. |
schema may be also a framing option ?
|
@bloodbare It would just be another node that could be expanded or compacted, like the However, before we attack framing, we need to get our This is also currently being discussed on the JSON-LD mailing list:
From: https://lists.w3.org/Archives/Public/public-linked-json/2016Jul/0005.html I also ran into this behavior with my PoC using the |
One other important issue we have to keep in mind is performance when we use framing. I did some research a while ago and it seems the framing algorithms all add a significant performance penalty to the request. @lukasgraf is there a way we can validate our responses? If so we could include that into our tests. |
@lukasgraf @tisto We are doing big progress on plone.server and we already implemented a framing option:
I know that all the autodiscovering of the json+ld is sweet, but after dealing with it on back performance on non json DB, with python implementations and how to work that on the front, I think its not what we need. |
I don't know, couldn't find anything after a quick search. Feeding the output through the framing/compaction algorithms using
In a way, I tend to agree. JSON-LD framing is basically a way to control how exactly a graph should be serialized to a tree. We (would) barely use any of all the possibilities that offers. We don't want to move nodes around, omit or replicate them. All we basically want is to collapse/expand certain nodes, depending on what the client asks for. That's a very small subset of what JSON-LD framing is capable of.
Yep. Basically we're aiming to use framing purely as a performance optimization, so the client can already have all the answers it needs inlined in the response instead of having to ask for it piece by piece by following 10 hypermedia links.
That's exactly how I would see framing being controlled in
I think an approach like that could very well be JSON-LD compliant, as long as every key / every node that can potentially be requested to be included in the response, is always present - but not necessarily in its expanded form. Also, every "framable" node would need to have a dedicated Whether or not we use a fully JSON-LD compliant library like Regarding performance: I agree this is something we need to keep an eye on, I haven't looked into that yet. Can you guys give some more details on that? I can't imagine that an offline transformation of a JSON-LD document with the complexity we're dealing with would add any significant penalty. Are we talking transformations where the algorithm is actually dereferencing IRIs (i.e, doing actual network requests)? I would rather see performance problems if you were to use the naive approach from my proof of concept above: Prepare everything we could ever need (schema, actions, ...) to generate a fully expanded document, and then collapse most of it and send it to the client. That would obviously need to work the other way round in an actual implementation. I haven't looked into this too much, but I think a document loader could be used for addressing that.
|
Closing for #149. |
The text was updated successfully, but these errors were encountered: