Re: [dxwg] A short token to specify a profile may be used as long as there is a discoverable mapping from it to the profile's identifying URI [ID5] (5.5) (#290)

(Sorry to be the one that replies to every single comment; trying to limit my interactions to the strictly necessary.)

> The motivation for catering for tokens is that existing profile negotiation systems (pyLDAPI, OAI-PMH, OGC Name Server) all use tokens.

Check, that's a good list. It would be helpful if you could answer these questions: https://github.com/w3c/dxwg/issues/290#issuecomment-525306101, the most important one being: do those clients all _know_ the token before they make a request?

> With the inclusion of tokens in `list profiles` responses, then the number of things client needs to know is reduced - just the resource URI.

Let's deconstruct that argument. If a client does a "list profiles", I am presuming that they _don't_ know the token they want, otherwise they wouldn't ask. So presumably, they are asking for a list of possible profiles, to then either harvest them all, or give the choice to a user or agent who _does_ know about tokens. So that is either a manual choice, or either there _is_ an agent who knows about the token. But that last case would negate he need to list the profiles, so only an interactive situation seems to fit.

Now if they client does _not_ know the token, why does it matter whether that token has the shape of the URI or whether it does not? I.e., what is the technical reason, for clients that know neither the token nor the URI and thus need a list, to prefer a non-URI string over a URI string?

So the number of things a client needs to know, does not seem to be reduced. The client needs some identifier for the profile, but I have not yet seen an argument for why it would matter whether that identifier is a URI or a non-URI.

> The additional client burden, if tokens are given by a server but not wanted by the client, is that the client just has to ignore them in the Link header.

So, we have established that:
- tokens _do not_ require extra work for clients that do not use them
- tokens _do_ require extra work for servers

But we have still not established that:
- tokens _do not_ require extra work for clients that use them

Or, refining that last point: is it really so much easier to retrofit existing negotiation systems with a mapping discovery process, only such that they can use non-URI identifiers for a profile?

-- 
GitHub Notification of comment by RubenVerborgh
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/290#issuecomment-526178972 using your GitHub account

Received on Thursday, 29 August 2019 13:13:18 UTC