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]
> *Sent:* Wednesday, 14 November, 2018 13:36
> *To:* pedro winstley <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
>     <mailto: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

Received on Wednesday, 14 November 2018 04:24:29 UTC