- From: Annette Greiner <amgreiner@lbl.gov>
- Date: Fri, 20 Sep 2019 09:46:15 -0700
- To: Rob Atkinson <rob@metalinkage.com.au>
- Cc: "Lars G. Svensson" <lars.svensson@web.de>, DXWG WG List <public-dxwg-wg@w3.org>
- Message-ID: <934216ce-8a51-fd6a-21eb-662e14d81a42@lbl.gov>
Another angle on this that occurred to me after responding is the behavior expected when the content negotiation is handled by an API that doesn't use query strings. The URLs would then be amenable to normal content negotiation, and the web server would have no way to know that there was an issue. It would have no choice but to handle the negotiation. What happens now if you try to configure conneg for a URL with a query string? I've not found any documentation addressing that case. We may have to experiment. -Annette On 9/19/19 9:47 PM, Rob Atkinson wrote: > I think the conflict case is better handled by defining the simplest > behaviour (which i think the spec does) and leave it to > implementations to sort out how to implement it. > > just passing QSA and headers to a Web Application is a very simple way > to implement - so concerns about how to finesse a particular HTTP > server to do some or part of this should be left out of scope. > > If we need to make this more obvious somehow then an editorial change > to improve wording can be considered. > > 1022 seems like a resolution would be an editorial change to ram home > to people with only one perspective that profiles can apply to both > behaviour and data. People familiar with profiles of services may > need to have it explained that data conforms to specifications too, > and vice versa. - but its only an issue of optimising explanatory text > to the extent possible with the inputs offered. > > > > > > On Fri, 20 Sep 2019 at 11:29, Annette Greiner <amgreiner@lbl.gov > <mailto:amgreiner@lbl.gov>> wrote: > > Thanks, Lars, for pulling all this together. I was out for a > couple of > key weeks on holiday and have been working through the 700 emails > that > ended up in my w3c mail folder during that time. So, I'm sorry that > these suggestions seem late, though they did seem to be under > discussion > by others pretty recently. > > My vote was to wait a bit before review and freezing, so that the > editors would have a chance to finish up the discussion about the > various issues still simmering and so that I would be able then to > vote > yes for moving to CR. When it became evident that there is no > willingness to wait on the freeze due to schedule constraints, I > switched to an abstention so as not to block things. > > Re the use of tokens, I support them for the case of a query > string but > not elsewhere. Removing all mention of them as identifiers > satisfies one > concern about how they are used. My other concern is just to keep > things > as simple as possible and avoid creating new required (if you use > tokens) headers. I saw the conversation about where the mapping from > token to URI should appear, and it occurred to me that that really > doesn't need to appear in headers if it appears in the returned > list of > options itself. That takes care of letting the client know what > token to > use in a query to that server. The preferred token is something > different, which I think would belong in the profile itself. As > long as > header-based negotiation can be done entirely with URIs, I think the > role of tokens can be quite limited. We do need to offer a mapping > between tokens and the profiles of datasets returned by a given > server, > but it doesn't need to be in headers. Technically, we wouldn't > even need > to do a mapping between tokens and URIs, but I think it would be best > practice to do it anyway. > > Re the handling of conflicts, I think we need to offer guidance to > developers of general-purpose server software that they can follow. > Since they already support content negotiation for media types and > languages, I would expect them to at least consider supporting conneg > for profiles. I don't think we should ask them to parse query > strings. > There are a few other options, though. We could ask them to drop > content > negotiation if there is a query string present, and to send the > request > forward as if the conneg directives for the URL were not present. > That > would have the effect of preventing any future innovative uses of > query > strings for negotiated content, and it would do the wrong thing > when a > user adds a query string by accident. We could say the server should > drop the query string and just do the content negotiation as if it > weren't there. This handles the user error case nicely but > probably does > the wrong thing for the case of misconfiguration half the time, > and it > again prevents innovative use of the combination. Or the server could > take a kind of literal approach and consider the query string as > part of > the mapping for the negotiation. That is, one could actually > configure > the server to handle negotiation for a URL with a specific query > string > and have it negotiate specifically for that case. > > There are a lot of cases here now that I think it all through. > Here is > what I would expect for the literalist approach: > > config request behavior > > conneg directive for URL w/out query string* query string > present** > pass to app > conneg directive for URL w/out query string query string not > present handle conneg (no conflict) > conneg directive for URL w/query string query string present > handle > conneg > conneg directive for URL w/query string query string not present > serve from file system or pass to app > no matching directive for URL query string not present serve from > file system or pass to app (no conflict) > no matching directive for URL query string present serve from > file system or pass to app (no conflict) > no matching directive for URL w/query string but directive for URL > w/out > query string query string present pass to app > no matching directive for URL w/out query string but directive for > URL > w/query string query string not present handle conneg > conneg directive for URL w/query string and URL w/out query string > query string present handle conneg for URL w/query string > conneg directive for URL w/query string and URL w/out query string > query string not present handle conneg for URL w/out query string > > *there is a directive in the server configuration that maps a URL > that > has no query string to a set of options. > **the client issues a request to the server for a URL that includes > query string arguments. > > > Here is the approach where QSA always wins: > > config request behavior > > conneg directive for URL w/out query string* query string > present** > pass to app > conneg directive for URL w/out query string query string not > present handle conneg (no conflict) > -conneg directive for URL w/query string query string > present pass > to app > conneg directive for URL w/query string query string not present > serve from file system or pass to app > no matching directive for URL query string not present serve from > file system or pass to app (no conflict) > no matching directive for URL query string present serve from > file system or pass to app (no conflict) > no matching directive for URL w/query string but directive for URL > w/out > query string query string present pass to app > -no matching directive for URL w/out query string but directive > for URL > w/query string query string not present pass to app > -conneg directive for URL w/query string and URL w/out query string > query string present pass to app > -conneg directive for URL w/query string and URL w/out query string > query string not present pas to app > > -differs from literalist approach > > I also have a comment on #1022 that hasn't been resolved, along > with Isaac. > > -Annette > > On 9/18/19 8:39 AM, lars.svensson@web.de > <mailto:lars.svensson@web.de> wrote: > > Dear Annette, > > > > I couldn't attend the DXWG meeting yesterday but read the > minutes [0]. From what I understand, you oppose to moving > conneg-by-ap to CR (first voting -1, then 0) as you "think there > are open conversations issues". > > > > You have been very helpful in shaping the work of the conneg > deliverable and have provided valuable feedback and as one of the > editors I'm contacting you to see if there is chance to resolve > those open issues so that we can move the specification forward to CR. > > > > My understanding is that your main points of critique are about > the use of tokens. That indeed seems to be the most > controversially discussed feature in the spec with comments > ranging from "tokens are completely unnecessary and their use > should be discouraged" to "tokens are an essential feature of > deployed APIs and we need to standardise their use in order to > improve interoperability". > > > > What I haven't understood yet is exactly where your position on > this is. From reading your comments in #453, #501 and #505, I get > the impression that you are not completely opposed to the use of > tokens but have concerns regarding how far it is possible to give > normative instructions on how to use them. > > > > In #453 (Consider use of adms:identifier instead of prof:token) > you say that the spec (in this case prof:) should not claim that > tokens are identifiers [1]. The editors of that spec have offered > to change the definition of prof:hasToken to accommodate that [2]. > Would that resolve that issue for you? > > > > In #501 (Registration of target attribute "profile" for the > Link-Header) I read your position to be that even if tokens in > some cases can be used to specify (or name) a profile, it is > unnecessary to provide a method to convey token/URI mappings in > http headers since that information can be transported in a > profile description (e. g. a human-readable document or an RDF > graph using prof:). In #501 you say that you have "not seen > discussion that convinces me that we really need token mappings" > and that we've moved away from the assumption that "a thing [sc. a > token] has the same standing as a URI and can be used in the same > ways" [3]. As seen in #290 [4], there is a plenary-approved > requirement for this kind of mapping and given that there has been > much discussion in that issue over the last four weeks I'm > surprised that you voice your concerns so late in the process. It > might be that we have moved away from the assumption that tokens > have the same standing as URIs but I don't see how that renders > tokens – or a machine-readable mapping from tokens to URIs – > useless. Can you expand a bit on exactly what is your concern here? > > > > In #505 (Specify the realisation order of precedence for > conflicting profile negotiation situations) I read your concern to > be that the conneg-by-ap spec would force _all_ http server > implementers to change their software to be compliant [5]. My > personal understanding of the spec's intention is that the order > of precedence is only relevant for server implementations that > implement _both_ QSA negotiation _and_ http negotiation as > specified in conneg-by-ap. If you agree with that I'd be happy to > discuss text edits that clarify that (assuming that the other > editors would agree...). > > > > I'm looking forward to your views on this and hope that we can > have it resolved in time for the vote. > > > > [0] https://www.w3.org/2019/09/17-dxwg-minutes > > [1] https://github.com/w3c/dxwg/issues/453#issuecomment-532420615 > > [2] https://github.com/w3c/dxwg/issues/453#issuecomment-532442529 > > [3] https://github.com/w3c/dxwg/issues/501#issuecomment-532436539 > > [4] https://github.com/w3c/dxwg/issues/290 > > [5] https://github.com/w3c/dxwg/issues/505#issuecomment-532441285 > > > > Best, > > > > Lars > > > -- > Annette Greiner (she) > NERSC Data and Analytics Services > Lawrence Berkeley National Laboratory > > > -- Annette Greiner (she) NERSC Data and Analytics Services Lawrence Berkeley National Laboratory
Received on Friday, 20 September 2019 16:46:49 UTC