Re: Moving conneg-by-ap to CR -- addressing concerns about the use of tokens

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 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

Received on Friday, 20 September 2019 01:30:16 UTC