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)

@rob-metalinkage 
Thanks for putting this together. Just some spontaneous remarks on the different options.

> Option 1:
> Server offers a 1:1 mapping from (optional) tokens to URIs using typical "parameter" syntax - we define the parameter "token"
>
> Accept-profile: URI[;token=mytoken],
>
> Pros: self-contained,flexible, explicit.
> Cons: potential redundancy in URIs if many offered

Should that be `Content-Profile: URI[;token=mytoken]`? Otherwise I don't understand from where the client gets the mappings of URIs to tokens. In my understanding the message exchange would be:
```
<request>
GET /some/resource HTTP/1.1
Accept-Profile: urn:example:profile:1

-----------
<response>
HTTP/1.1 200 OK
Content-Profile: urn:example:profile:2;token=profile-2

------------
<new request, now the client knows that urn:example:profile:2 is bound to the token profile-2>
GET /some/other/resource HTTP/1.1

Accept-Profile: profile-2
```

> Option 2:
> tokens are registered in a global registry and servers may use them in place of a URI

This is the cleanest solution. If it works really depends on how many profiles will be registered (and by whom...). For some organisations it can be too complex to register profiles. OTOH could something like prefix.cc for profiles be a solution (or maybe re-use prefix.cc!).

> Option 3: allow namespace declarations - like in JSON CURIE (compact URI - declare namespaces)
> Accept-profile: @:,@ns2:<namespace2, :token1, w3c:token2

Sorry, My brain cannot parse that syntax... Can you provide an example?

> Option 4: add a namespace header

Do I understand correctly that this would mean that tokens are not global identifiers but only valid in the context of the specified namespace?

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

Received on Saturday, 16 February 2019 14:51:12 UTC