Re: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129

On 19 May 2013 11:54, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> 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
>
>
Hi Markus,

That wording works well for me, so my concerns are addressed.

Peter