- From: aisaac via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Aug 2019 17:12:14 +0000
- To: public-dxwg-wg@w3.org
Hi @larsgsvensson , thanks for coming back to this! 1, 2, 3, 8, 9, 10, 12, 13, 14 can be considered addressed indeed. For the others: .4. Yes. Note that I'm agnostic wrt #380 .5,6,7. Yes. Indeed, renaming the subsection may improve the situation. Still it would be better to sort out what's about context from what's about proposals in the doc. And 7 is quite a contradiction with other parts. .11. Yes .15. Yes. Re-writing could be better than adding another example but I leave it to the editors :-) .16. I'm split. There's now a motivation paragraph, so in principle my comment is addressed. Yet I'm puzzled by "it is also advisable to enable humans to select data by profile without requiring direct manipulation of request header content" and the rest. QSA are of course easier for humans, but there are tools that can help manipulate these headers. And the motivation given for QSA supposes that humans are helped by a web development tool, so they could pick one that helps manipulating headers. In addition, is human access the sole motivation for QSAs? I could imagine that some web programming styles/constraints could also give a motivation for prefering QSAs over header-based negotiation. .17. I understand that there is a contradiction, but I will consider it's not related to my original comment anymore, as the contradictions within the text seems to be fixed now! .18. Yes. .19. Yes, but this is apparently Example 11 now. Note that my issue was the HTML bit. There's nothing obviously about HTML in `GET /a/resource?_profile=aaa,bbb,ccc HTTP/1.1`. So the renaming you suggest could be lighter. Or it could be solved by changing the query itself! -- GitHub Notification of comment by aisaac Please view or discuss this issue at https://github.com/w3c/dxwg/issues/575#issuecomment-518760959 using your GitHub account
Received on Tuesday, 6 August 2019 17:12:16 UTC