W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > September 2019

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

From: <lars.svensson@web.de>
Date: Wed, 18 Sep 2019 17:39:30 +0200
Message-ID: <trinity-31875c6b-4fda-45cc-9a57-2145b0d32e07-1568821170079@3c-app-webde-bap25>
To: amgreiner@lbl.gov
Cc: "DXWG WG List" <public-dxwg-wg@w3.org>
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 


Received on Wednesday, 18 September 2019 15:39:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:20 UTC