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

That's good to hear, Nick!

Could we just say that in order to conform to this spec, an 
implementation needs to conform to the abstract model? All this extra 
stuff about having a functional profile seems like a lot of extra work.
-Annette

On 9/26/19 12:51 AM, Nicholas Car wrote:
> Hi all,
> *
> *
> There is a way through here and it comes down to a small wording change.
>
> *> 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.*
>
> You refer to Section 7.2 
> (https://w3c.github.io/dxwg/conneg-by-ap/#conformance-profiles) and 
> you are correct:
>
> “If a system wishes to show conformance to this specification, 
> conformance to at least one of the functional profiles listed inFigure 
> 2 
> <https://w3c.github.io/dxwg/conneg-by-ap/#fig-table-profiles>/MUST/be 
> indicated.”
>
> The wording change should be to:
>
> “If a system wishes to show conformance to this specification, 
> conformance to at least one functional profile of it, such as those 
> listed inFigure 2 
> <https://w3c.github.io/dxwg/conneg-by-ap/#fig-table-profiles>/MUST/be 
> indicated.”
>
> Our mistake here is to have made that table listing Functional 
> Profiles seem to be close, no more FPs allowed. That has never been 
> the intention and this is spelled out in many other places in the 
> spec. The rule, as per Section 6 
> (https://w3c.github.io/dxwg/conneg-by-ap/#abstractmodel) is only that:
>
> “...to be a valid functional profile 
> <https://w3c.github.io/dxwg/conneg-by-ap/#dfn-functional-profile> they 
> /MUST/ implement these Abstract Model functions. How they do this will 
> be environment-specific.”
>
> and:
>
> “it is expected that implementers will want to implement methods, and 
> thus Functional Profiles of the Abstract Model, for other 
> environments, some of which may not yet be realized – future 
> environments.”
>
> So the wording change will address Annette’s request that conformance 
> to the listed FPs not be normative.
>
> Additionally:
>
> *
> *
> *> There are multiple ways to implement conneg by URL. *
>
> Indeed. By presenting two Functional Profiles for doing Conneg by P 
> using URLs we indicate this is in the specification.
>
> *> 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*
>
> You, and anyone else, are free to make a FP of the spec for your 
> needs. The rule, as per Section 6 
> (https://w3c.github.io/dxwg/conneg-by-ap/#abstractmodel) is only that:
>
> “...to be a valid functional profile 
> <https://w3c.github.io/dxwg/conneg-by-ap/#dfn-functional-profile> they 
> /MUST/ implement these Abstract Model functions. How they do this will 
> be environment-specific.”
>
> We are showing that there are two “environments” in which URLs may be 
> used so there may also be more.
>
> *> I don't think it would make sense to offer two versions of QSA 
> anymore.*
>
> We have motivating use cases for each: they are all about how well 
> existing systems already doing Conneg by P may be enhanced to match 
> this spec.
>
>
> Will this solve the problems? If so I will make a PR for that wording 
> change.
>
> Nick
>
> —
> Nicholas Car
> Data Systems Architect
> SURROUND Australia
> 0477 560 177
> nicholas.car@surroundaustralia.com 
> <mailto:nicholas.car@surroundaustralia.com>
>
> On 26 Sep 2019, at 5:01 am, Annette Greiner <amgreiner@lbl.gov 
> <mailto:amgreiner@lbl.gov>> wrote:
>
>> 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
>>
>>
-- 
Annette Greiner (she)
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory