- From: Nicholas Car via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Apr 2019 12:05:03 +0000
- To: public-dxwg-wg@w3.org
> that the query string treatment should not be normative 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. If you do implement a QSA approach then you should do so according to the QSA Realization. > if we give an informational example of handling the choice of a profile via a browser, we should offer something that is a better example for human use. Please make a suggestion! We have lots of APIs that use a primitive QSA version of the Realization outlined here and they work quite well. We hope that future APIs adhering to this QSA will work better, for humans, and will accord with the HTTP Realization. "better example for human use" doesn't really give us anywhere to go unless you can either point out an un-met Use Case or perhaps a demo solution you must have in mind. > ...there exists no prior standard for handling content negotiation with query strings Motivation indeed to make one if it were true! There are plenty of standards though: [OAI-PMH](https://www.openarchives.org/pmh/) for one. Fixed to XML for Content-Type sure but it's all about negotiating by profile, e.g.: Sample AU1 from the Geoscience Australia in "Dublin Core" profile: http://ldapi.ga.gov.au/sss/oai?verb=GetRecord&identifier=AU1&metadataPrefix=oai_dc Sample AU1 in "CSIROv3" profile: http://ldapi.ga.gov.au/sss/oai?verb=GetRecord&identifier=AU1&metadataPrefix=csirov3 > If such a thing is needed at all, it would make the most sense to develop it in the context of existing use cases of content negotiation, such as language and media type Do you mean like this one: https://github.com/w3c/dxwg/issues/239 to which I see you've commented "[I think this use case is extremely important and fully in scope](https://github.com/w3c/dxwg/issues/239#issuecomment-402859160)"? Do you mean we should define, in a QSA Realization, how conneg by profile works within a context of conneg by Content Type & conneg by Language? That's what we are doing so I don't follow. > If we offer a method of enabling humans to select a dataset by profile, we should be modeling good usability, where the user is shown a list of options and simply selects the one they prefer. Our use case comes down to allowing users to select, not to negotiate. Can you make a proposal? > prescribing a specific way of coding a web application goes against the freedom web developers expect in building applications. Development practices change rapidly, and at any given time there is little agreement on the "right way" to do something. In particular, there has been much debate about the use of query strings in REST-based web applications. The goal here is to present an Abstract Model with 2+ Realizations. HTTP as the Internet's core and QSA for a more human-usable form. We need 2+ to prove the point. Feel free to contribute a GraphQL API. I might consider that as a WG note anyway. > In addition to creating issues for human consumption of datasets, the use of query strings for negotiation may also have an unintended side-effect for programmatic access. It introduces the possibility that developers will use query strings instead of http headers The API tooling I use that implements a precursor of this handles both HTTP & QSA negotiation. A precedence order is given (anything human-set wins over machine-set so QSA tends to win over HTTP) but either approach many be used. > developers will use query strings instead of http headers So what? You just mentioned "Development practices change rapidly, and at any given time there is little agreement on the "right way" to do something" so why should developers not use QSA (or GraphQL if implemented?) > The query string approach is also the main driver for the use of tokens to identify profiles. Tokens without some sort of registry or other means of enabling discovery and minimizing conflict are problematic. Without a requirement for query strings, a URI could serve as a single universal identifier for a profile. True, QSA is the driver for tokens and we have been over the mechanics of this a few times: tokens can be used as long as they deterministically map to a URI within a client/server session. Seems sound... > Making query-string profile negotiation normative overreaches our charter... Again, we are not saying that any implementation of conneg by profile is required to implement all Realizations. > ...models poor usability for humans... It's designed to be easier to use, by humans, than HTTP conneg so you'll have to unpack this one if you're to convince me! > ...and blocks the assignment of unique profile IDs How so? A profile definition, by PROF and as recommended by Guidance, will be identified by URI. -- GitHub Notification of comment by nicholascar Please view or discuss this issue at https://github.com/w3c/dxwg/issues/544#issuecomment-479869859 using your GitHub account
Received on Thursday, 4 April 2019 12:05:05 UTC