- From: Annette Greiner via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Mar 2019 19:16:43 +0000
- To: public-dxwg-wg@w3.org
I think I need to be more clear about my concerns with the query string negotiation. They are twofold, first that the query string treatment should not be normative, and secondly that 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. Our charter calls for development of content negotiation by profile. Nothing in that document suggests a requirement to offer a query-string-based specification for handling profiles. I see no reason to think that such a thing would even be implied by the charter, as there exists no prior standard for handling content negotiation with query strings. 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. Offering normative specifications for a query-string-based negotiation method is overreaching our charter. The use case on which this work is based is about making the choice of a profile easy for humans. We agreed to that use case because the header-based negotiation creates something of a black box for users, and it is not made available to users by browsers. Indeed, the whole point of content negotiation is to enable a behind-the-scenes selection that the user need not think about. The problem is that, in the case of a human consumer of datasets, it makes sense for them to have agency in the choice of profile. Forcing them to suffer through the experience of negotiation by faithfully replicating that black box does not help users. Requiring non-developer users to be aware of a fine detail in a standards document, know whether to apply it to a given site, and type in a correct URL is anything but user friendly. 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. Aside from the danger of specifying a usability nightmare, 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. Calling a specific implementation normative is tantamount to taking sides in that debate. We risk alienating developers and creating a standard that ages quickly. 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, creating a competing approach for programmatic access, making the web of data more complex and difficult to use. We may caution people to use both techniques, but the likelihood is that people will use what they like and avoid the extra work. 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. To be clear, there is nothing technically wrong with creating a means of using query strings to pass user choices to an API, especially if it enables a usable graphical solution for user profile selection, but it is that graphical selection that we need to exemplify, not the API itself, and not negotiation. One could just as well use an API that accepts URLs without query strings. Not every web API deserves to become a standard. Making query-string profile negotiation normative overreaches our charter, models poor usability for humans, risks alienating developers, competes with header-based authentication, and blocks the assignment of unique profile IDs. Unless this is addressed, I don't see myself voting to publish the profile negotiation document. -- GitHub Notification of comment by agreiner Please view or discuss this issue at https://github.com/w3c/dxwg/issues/544#issuecomment-474535369 using your GitHub account
Received on Tuesday, 19 March 2019 19:16:44 UTC