Re: Regrets

Asking for a list of options and picking one is still arguably
"negotiation" - although "mediation" might also apply. the IETF RFC merely
states

" content negotiation The mechanism for selecting the appropriate
representation when servicing a request."

It does not explicitly require support for lists of choices.

This description
https://en.wikipedia.org/wiki/Content_negotiation#Agent-driven explicitly
includes the case where a list is provided and the client chooses - but I
don't see where a specification that defines this is referenced.

Then there is the sense that QSA may be multi-valued - there are no
examples given, but this fits the sense of a list

And finally there are the issues which do need an issue raised IMHO,  about
use of wildcards and returning a more specific profile given identifier of
a general one. (these both occur in MIME type conneg, you dont have to
specify sub-profiles of MIME types, but you may receive one.)







On Wed, 14 Nov 2018 at 15:53, <Simon.Cox@csiro.au> wrote:

> Thanks for clarification Annette. Indeed, I had not picked up the
> distinction.
>
>
>
> *From:* Annette Greiner [mailto:amgreiner@lbl.gov]
> *Sent:* Wednesday, 14 November, 2018 15:24
> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>;
> pedro.win.stan@googlemail.com; public-dxwg-wg@w3.org
> *Subject:* Re: Regrets
>
>
>
> I'm distinguishing between negotiating for content and requesting specific
> content. I've not seen negotiation handled this way (where one indicates a
> list of acceptable options and gets a response chosen by the server),
> though I admit I may just not be aware of implementations. File-type
> suffixes allow selection of a particular file; they are not negotiation.
> Typical REST implementations provide another way to select specific files
> with a URL string as well, but those are not negotiations either.
>
>
>
> On 11/13/18 8:49 PM, Simon.Cox@csiro.au wrote:
>
> Ø  Enabling multiple ways to handle content negotiation doesn't seem like
> a win to me, as using query strings is not a standard way of doing content
> negotiation otherwise, so that is a departure from current conneg standards.
>
>
>
> Conneg using paths other than HTTP headers has been a common practice.
> File-type suffixes are the most obvious pattern. The Linked Data API that
> was developed primarily in UK government circles introduced some ‘standard’
> QSA keys like _format, _view, _metadata quite a few years ago. It is true
> that they didn’t get adopted as a standard and I guess you could argue that
> this was because the idea was flawed, but it was responding to a clear need
> which I don’t think has gone away.
>
>
>
> *From:* Annette Greiner [mailto:amgreiner@lbl.gov <amgreiner@lbl.gov>]
> *Sent:* Wednesday, 14 November, 2018 13:36
> *To:* pedro winstley <pedro.win.stan@googlemail.com>
> <pedro.win.stan@googlemail.com>; public-dxwg-wg@w3.org
> *Subject:* Re: Regrets
>
>
>
> I guess I never did it explicitly, but I meant to vote +1 for publishing
> the prof ontology.
>
> Sorry, but for conneg I have to vote -1 until a couple of issues have been
> addressed.
>
> We have two outstanding substantial issues with the conneg doc that I
> would like to see at least marked prominently. One is the presentation of
> the QSA stuff as normative. It should not be normative. Alejandra pointed
> that out quite a while ago, I believe, and I agree. The conneg doc is about
> a standard for header-based content negotiation, and I think it is beyond
> our charter to give normative requirements for a QSA-based approach to
> conneg. I thought this was agreed by the editors, but the document still
> treats that section as normative.
>
> In addition, I opened a second issue about the use of QSA to specify a
> second way of conducting content negotiation rather than as an example of
> how to enable discovery and selection of profiles by using query strings
> (#544).  I strongly supported a requirement for the latter, because it is
> necessary to enable human users to understand what is available and
> recognize when the data available are limited to a specific profile.
> Enabling multiple ways to handle content negotiation doesn't seem like a
> win to me, as using query strings is not a standard way of doing content
> negotiation otherwise, so that is a departure from current conneg
> standards. It may even be harmful, as it creates ambiguity as to whether
> content negotiation is available, since one would have to check both
> methods to determine that it was not available. Rather than addressing the
> issue of how negotiation obscures the choice of profile made behind the
> scenes for human users, it re-creates that problem in a new form. Finally,
> this additional approach is introducing new problems because it requires
> determination of how to handle situations where both types of negotiation
> are attempted.
>
> -Annette
>
>
>
> On 11/13/18 3:01 PM, pedro winstley wrote:
>
> Hi Annette
>
> Did you vote on the proposals for publication?
>
>
>
> On Tue, 13 Nov 2018, 21:00 Annette Greiner <amgreiner@lbl.gov wrote:
>
> Sorry, I won't be able to make today's meeting.
> -Annette
>
> Sent from my iPhone
>
>
>
>
> --
>
> Annette Greiner
>
> NERSC Data and Analytics Services
>
> Lawrence Berkeley National Laboratory
>
>
>
>
>
> --
>
> Annette Greiner
>
> NERSC Data and Analytics Services
>
> Lawrence Berkeley National Laboratory
>
>
>
>