- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Sat, 18 May 2013 22:54:07 -0300
- To: "'Linked JSON'" <public-linked-json@w3.org>, "'Peter Ansell'" <ansell.peter@gmail.com>
- Cc: <public-rdf-comments@w3.org>
I just had a chance to look at the minutes and have a couple of questions. Unfortunately I'll be on a plane on Tuesday so I would like to discuss these things beforehand on the mailing list. Peter, I'm sending this mail to you directly as well as there's a question for you at the very bottom. > Topic: RDF-ISSUE-129: Lossless conversion > [...] > Gregg Kellogg: I wonder if the flag is in the wrong place > Gregg Kellogg: perhaps there should be an expansion flag such > that when we expand we turn all numeric data types into ? data > types so that the consumers can choose how data is handled > Sandro Hawke: I like that Could you please explain in detail how the change you propose would look like? We did that quite some time ago but decided to move the conversion between native types and strings to to/from RDF because that's where the complexity has to live. If you are staying within JSON-LD you shouldn't have to worry (or even know) about that. > Sandro Hawke: we many need to refer to a different spec > regarding futures - the DOM WHATWG one might change. > Sandro Hawke: hard requirement is to refer to stable things. it > is hard to argue that the "living spec" is stable > ... not saying we change the reference, but change how we use > the reference > Manu Sporny: We don't actually reference the Futures spec > directly. We only use the Future concept in our spec, not the API > itself. > Sandro Hawke: if they change Futures, then every piece of > software using futures would be broken and have to change > Manu Sporny: Being pedantic, but the spec wouldn't change, just > the implementation. > Sandro Hawke: The director probably won't be okay with that. You > shouldn't build on specs that are not stable > ... We have to hard-code it with the current view of futures > so that if it changes, we use the old version of futures Hmm... that kind of surprises me. JSON itself e.g. is not a IETF standard but just an informational note. HTML5 is referencing a large number of living standards: http://www.w3.org/html/wg/drafts/html/master/iana.html#references In this case I think it makes no sense to hardcode the reference to a specific version because as Manu says, we just use the concept of a Future. The JSON-LD API should be based on what browser vendors implement - and that will be the WHATWG living standard. > Topic: RDF-ISSUE-128: Mandatory profiles > [...] > Gregg Kellogg: question is, can a server respond with any time, > even if it doesn't match what's in the ACCEPT header. > Gregg Kellogg: … This includes type parameters, needs research. > Manu Sporny: > http://lists.w3.org/Archives/Public/public-rdf- > comments/2013May/0038.html > Manu Sporny: if the above satisfies Peter's comments then we > should use that. > Niklas Lindström: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html > Niklas Lindström: it sounds like we're restating the rules of > content negotiiation > Stian Soiland-Reyes: I don't think you need to do 406 if it's > just the profile parameter that can't be satisfied (it might be > satisfied, the server just don't know that) > Manu Sporny: we need to make sure we're not duplicating spec > text Peter already clarified that <snip> [he] would be satisfied if the following passage in Section E, "The profile parameter may be used by clients to express their preferences in the content negotiation process." was modified to something like: "The profile parameter MAY be used by clients to express their preferences in the content negotiation process. If the profile parameter is given a server SHOULD return a document that is structured based on the profiles in the list which are recognized by the server." </snip> http://lists.w3.org/Archives/Public/public-rdf-comments/2013May/0034.html >From listening to the audio, you weren't sure whether a server MUST be return a 406 Not Acceptable if it can't honor the profile. That's certainly not true - in fact most existing systems don't do that (as Manu already said). The thing we are talking about here is called proactive negotiation. Here's the relevant snippet from the HTTP spec: A user agent cannot rely on proactive negotiation preferences being consistently honored, since the origin server might not implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to the user agent's preferences is better than sending a 406 (Not Acceptable) response. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-3.4.1 I would thus like to make the following PROPOSAL: Change the following passage in Section E, "The profile parameter may be used by clients to express their preferences in the content negotiation process." to: "The profile parameter MAY be used by clients to express their preferences in the content negotiation process. If the profile parameter is given a server SHOULD return a document that honors the profiles in the list which are recognized by the server." The only change I made to Peter's proposal is to generalize the "structured based on the profiles" to "honors the profiles". Peter, would that would that address the concerns you raised in RDF-ISSUE-128: http://www.w3.org/2011/rdf-wg/track/issues/128 Cheers, Markus -- Markus Lanthaler @markuslanthaler
Received on Sunday, 19 May 2013 01:54:42 UTC