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

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