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

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

From: Lars G. Svensson <lars.svensson@web.de>
Date: Wed, 25 Sep 2019 21:37:22 +0200
To: Annette Greiner <amgreiner@lbl.gov>
Cc: DXWG WG List <public-dxwg-wg@w3.org>
Message-ID: <21c8a8ce-8602-4b03-a2b5-0596b5e76e71@web.de>
The way I read it, it's a functional profile nonetheless. Let's see what
Rob and Nick say to that.



Am 25.09.2019 um 21:32 schrieb Annette Greiner:
> "conformance to at least one of the functional profiles"
> There are three functional profiles in that table as far as I can
> tell. The fourth item in the table seems to be just showing how a
> resource can indicate which representations it makes available, which
> is a small part of the abstract model. It doesn't offer a way to
> accomplish it as the functional profiles do.
> On 9/25/19 12:16 PM, Lars G. Svensson wrote:
>> > 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.
>> The new section about conformance to functional profiles (ยง7.2)[1] says:
>> "This specification defines several functional profiles
>> <https://w3c.github.io/dxwg/conneg-by-ap/#dfn-functional-profile> that
>> may be conformed to by systems. These functional profiles are identified
>> by URIs and given in the table below."
>> <definition of profiles>
>> "If a system wishes to show conformance to this specification,
>> conformance to at least one of the functional profiles listed in Figure
>> 2 <https://w3c.github.io/dxwg/conneg-by-ap/#fig-table-profiles> /MUST/
>> be indicated. "
>> This means that if a server conforms to cnpr:rrd (a resource
>> representation indicates which profiles it conforms to) it implements
>> the spec, even if it doesn't do any content negotiation at all.
>> [1] https://w3c.github.io/dxwg/conneg-by-ap/#conformance-profiles
>> Best,
>> Lars
>> Am 25.09.2019 um 21:01 schrieb Annette Greiner:
>>> 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.
Received on Wednesday, 25 September 2019 19:37:51 UTC

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