W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > September 2019

Re: Moving conneg-by-ap to CR

From: Annette Greiner <amgreiner@lbl.gov>
Date: Wed, 25 Sep 2019 12:43:17 -0700
To: "Lars G. Svensson" <lars.svensson@web.de>
Cc: public-dxwg-wg@w3.org
Message-ID: <7b3d8517-61a0-ce1c-b6d5-ae42d40175b4@lbl.gov>
Yes, they are essentially the same. There is no indication in the spec 
that it would be acceptable to architect one's app without using query 
strings. Merely removing the less lenient one would be a step in the 
wrong direction, IMHO. If it were replaced with a non-query string 
realization, and both realizations were described as suggestions rather 
than MUSTs, that would be an improvement.

On 9/25/19 12:31 PM, Lars G. Svensson wrote:
> To me they are essentially the same, only that one mandates which keys 
> are to use whereas the other one is more lenient.
> Would it make things more clear to you if we removed the "QSA 
> Alternate Keywords Functional Profile"? That would need a discussion 
> with Rob and Nick that I won't be able to participate in (it's getting 
> late here but soon it'll be morning in Australia...)
> Best,
> Lars
> Am 25.09.2019 um 21:09 schrieb Annette Greiner:
>> I'm referring to what are currently termed the "QSA Functional 
>> Profile" and the "QSA Alternate Keywords Functional Profile". And I 
>> see that the conformance info has been moved to section 7.2.
>> On 9/25/19 11:48 AM, Lars G. Svensson wrote:
>>> I have the impression that we're not looking at the same document: In
>>> the current ED there is no §2.1 since that content has moved to §7...
>>> I also don't understand where you see two similar QSA approaches.
>>> And I fully agree that not all web developers agree that query string
>>> negotiation is the best way of doing negotiation. We also don't mandate
>>> that (just as we don't mandate the use of http negotiation). QSA is one
>>> way of doing it. If a web developer wants to implement profile
>>> negotiation without query strings, she is free to do that. But if she
>>> does it with query strings, we want to keep that interoperable, and
>>> that's why we say "this is the way to do it". So we're in full 
>>> agreement
>>> "that there are many ways in which one can use the abstract model to
>>> code up a content negotiation strategy and the QSA approach offers one
>>> of them." Can you point me (and Nick and Rob) to text passages that
>>> claim differently and preferably also propose text that resolves 
>>> your issue?
>>> Thanks,
>>> Lars
>>> Am 25.09.2019 um 20:03 schrieb Annette Greiner:
>>>> The issue about whether that section is normative needs to be resolved
>>>> for me to support moving to CR. It's particularly troubling to me
>>>> since I did rewrite that section to address that, the changes were
>>>> accepted, and then they were somehow edited back out by subsequent
>>>> work. I realize the editing process can be chaotic with many
>>>> contributors, so I'm not looking to blame anyone for this. My goal had
>>>> been and remains to clarify that there are many ways in which one can
>>>> use the abstract model to code up a content negotiation strategy and
>>>> the QSA approach offers one of them. Since that rewrite, the document
>>>> now offers two similar QSA-based approaches and a statement in section
>>>> 2.1 that conformance to one of them or to header-based conneg is
>>>> required for conformance to the spec. That isn't what we agreed to. My
>>>> main concern with this is to acknowledge that web developers do not
>>>> all agree that query strings are the best way to handle
>>>> differentiating requests, and I don't think that we should be in the
>>>> position of legislating development styles.
>>>> -Annette
>>>> On 9/25/19 10:05 AM, lars.svensson@web.de wrote:
>>>>> Dear all,
>>>>> Thanks for giving us editors of conneg-by-ap another 24 hours to fix
>>>>> open issues with the document. We have addressed the following:
>>>>> 1. The syntax for Accept-Profile now uses angle brackets around the
>>>>> URIs in order to cleanly separate the profile URI from q-values,
>>>>> other parameters or other profile URIs [0,1]. This resolves Rob
>>>>> Sanderson's first objection. A question has been sent to Rob if he is
>>>>> satisfied with the outcome [2] and he has confirmed this [3].
>>>>> 2. The three issues that were still in the document have been removed
>>>>> since they were either closed already (#1041) or had been resolved
>>>>> but not closed (#290) or resolved but without any response from the
>>>>> original poster over four weeks (#678). This resolves Rob Sanderson's
>>>>> second objection. A question has been sent to Rob if he is satisfied
>>>>> with the outcome [2] and he has confirmed this [3].
>>>>> 3. The document now contains a definition of "functional profile" in
>>>>> the definition section [4] while all other text about functional
>>>>> profiles is now in its own section in §7 [5,6]. This resolves 
>>>>> #1022 [7].
>>>>> What we have not been able to address is the question about order of
>>>>> precedence for conflicting profile negotiation situations (#505)[8].
>>>>> My understanding is that Annette requires that QSA is made
>>>>> non-normative while Nick and Rob are not willing to step down from a
>>>>> full standard. I have asked Annette if this issue is a blocker for
>>>>> her [8].
>>>>> Regarding wide review, Peter had sent out a request for comments on
>>>>> the 2PWD [9]. Following that, we've had responses on the comments
>>>>> list and outside Github comments from at least Kam Hay Fung
>>>>> [10,11,17], Erik Wilde [12], Herbert van der Sompel [13], Andreas
>>>>> Kuckartz [14] and Gregg Kellogg [15, resolved in 16]. Following a
>>>>> request from Nick [18], we also had feedback from CKAN developers
>>>>> [19,20]. This shows involvement of the outside community. I have also
>>>>> added this to the transition request document [21].
>>>>> With five hours left, there is little left for us editors to do,
>>>>> except to ask you to cast your votes again.
>>>>> The editors of conneg-by-ap
>>>>> Nick, Rob and Lars
>>>>> [0] 
>>>>> https://w3c.github.io/dxwg/conneg-by-ap/#http-getresourcebyprofile
>>>>> [1] https://w3c.github.io/dxwg/conneg-by-ap/#eg-http-get
>>>>> [2]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Sep/0914.html
>>>>> [3]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Sep/0915.html
>>>>> [4] https://w3c.github.io/dxwg/conneg-by-ap/#definitions and
>>>>> https://raw.githack.com/w3c/dxwg/larsgsvensson-functional-specification/conneg-by-ap/index.html#definitions 
>>>>> [5]
>>>>> https://w3c.github.io/dxwg/conneg-by-ap/#functional-profiles-definition 
>>>>> [6] https://w3c.github.io/dxwg/conneg-by-ap/#conformance-profiles
>>>>> [7] https://github.com/w3c/dxwg/issues/1022
>>>>> [8]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Sep/att-0913/00-part 
>>>>> [9]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-comments/2019May/0002.html 
>>>>> [10] https://github.com/w3c/dxwg/issues/785
>>>>> [11] https://github.com/w3c/dxwg/issues/835
>>>>> [12] https://github.com/w3c/dxwg/issues/501#issuecomment-522503214
>>>>> [13] https://github.com/w3c/dxwg/issues/501#issuecomment-522523315
>>>>> [14] https://github.com/w3c/dxwg/issues/290#issuecomment-466656384
>>>>> [15] https://github.com/w3c/dxwg/issues/662
>>>>> [16]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Apr/0001.html 
>>>>> [17]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-comments/2018Aug/0002.html 
>>>>> [18]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Sep/att-0907/00-part 
>>>>> [19]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Sep/att-0908/00-part 
>>>>> [20]
>>>>> https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Sep/att-0910/00-part 
>>>>> [21]
>>>>> https://github.com/w3c/dxwg/wiki/Conneg:-Draft-Transition-Request-to-CR 
>> --
>> Annette Greiner (she)
>> NERSC Data and Analytics Services
>> Lawrence Berkeley National Laboratory
Annette Greiner (she)
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
Received on Wednesday, 25 September 2019 19:43:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:21 UTC