- 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>
The way I read it, it's a functional profile nonetheless. Let's see what Rob and Nick say to that. Best, Lars 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