These are chat archives for csarven/ldn

1st
Jul 2016
Amy Guy
@rhiaro
Jul 01 2016 18:54
So right now we don't say anything about what the server must return for the notification itself, only for the contents of the Inbox container. If we say that notifications themselves must be returned as JSON-LD, current LDP/solid implementations don't conform, as if it was posted in a different syntax they won't reserialise it. And in this case, Accept-Post for the send is actually completely pointless.
The receiver doesn't actually care what the payload is. Accept-Post was just a way for the receiver to try to help with communication between sender and future consumer. Except it doesn't work, because we don't specify anything about the notification syntax as far as the consumer is concerned.
Ultimately the payload can be a black box as far as the receiver is concerned. Like solid servers, they accept anything without trying to understand it.
So in order to guarantee senders sending something that consumers they've never met can understand, we have to say json-ld all around
or we have to say receivers must understand the payload enough to reserialise it to JSON-LD if it isn't already
Otherwise, it's all very well a consumer being able to say Accept: application/ld+json on the inbox, but when they try to fetch the notifications themselves there's no telling what they'll get, which is entirely unhelpful.
So to rectify this we have 2 options:
Amy Guy
@rhiaro
Jul 01 2016 18:59
  1. The receiver MUST provide the individual notifications as JSON-LD, regardless of what they were written as (drawback: Solid/LDP servers do not comply out of the box)
\2. The sender MUST send JSON-LD. No negotiation. (drawback: turtle is nice; dokieli doesn't currently conform)