Re: [dxwg] Query string implementation of profile selection (#544)

To your first question, no, I don't think conneg by header should be 
non-normative. I see the two options as conneg by header and conneg by 
URL. (BTW, I also dislike seeing header negotiation called http 
negotiation. HTTP URLs are part of http, too.) There are multiple ways 
to implement conneg by URL. Conneg by URL is intended for human use, so 
machine interoperability is secondary there. But, like any API, it's 
best to enable interoperability by the techniques we're all familiar 
with for making an API interoperable. Those techniques do not extend to 
requiring a specific coding stye. If you were to somehow convince me 
that it should, then we would need to hash out the old debate about 
clean URLs vs query strings, and we'd have to discuss the choices of 
keywords and values, and which architectural style should rule them all, 
and I don't think it would make sense to offer two versions of QSA 
anymore. I've not wanted to get into all that, because there is not a 
consensus among developers, so that would be a difficult debate.

To your second question, I agree with that quote from Nick, but the spec 
currently doesn't. The spec currently says in section 2.1 that one of 
the three "functional profiles" must be used in order to claim 
conformance with the spec.

-Annette

On 9/25/19 11:41 AM, Lars G. Svensson wrote:
> Does this mean that you think we should declare http conneg as
> non-normative, too, since it's only one of several possibilities to
> implement the abstract model? (One could for instance register other
> headers to do that).
>
> To me the important part of Nick's comment is that it's not normative to
> have to implement a QSA API. It only says that if you implement
> conneg-by-ap using query strings, this is the way to do it. Why do you
> oppose to that?
>
> Best,
>
> Lars
>
> Am 25.09.2019 um 19:32 schrieb Annette Greiner:
>> I'll quote Nick's email from back in April here:
>>
>> "What is normative is that one adheres to the Abstract Model for any
>> Realizations. It's not normative to, for instance, have to implement a
>> QSA API just because you implemented an HTTP API according to the
>> Abstract Model."
>>
>> -Annette
>>
>> On 9/24/19 9:52 PM, Lars G. Svensson via GitHub wrote:
>>> A further comment from @agreiner that came over the [mailing
>>> list](http://lists.w3.org/Archives/Public/public-dxwg-wg/2019Sep/0872.html) 
>>>
>>> as a reply to [Karen's
>>> comment](https://github.com/w3c/dxwg/issues/544#issuecomment-534764141): 
>>>
>>>
>>>> Looking back at my big edit on that section, I did say "Unlike the
>>>> HTTP-header realization, which is also the subject of an independent
>>>> IETF document [PROF-IETF], this realization is fully specified here,
>>>> though it is not normative."
>>> I thought we had agreed that the QSA realization was not to be
>>> normative. There was general approval to my edits when I submitted
>>> them, except that Nick wanted to keep the original heading, as I 
>>> recall.
>>
-- 
Annette Greiner (she)
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory

Received on Wednesday, 25 September 2019 19:01:28 UTC