<LarsG> +1
+1
<roba> +1
<LarsG> https://www.w3.org/2019/08/22-dxwgcneg-minutes
<LarsG> +1
<roba> +1
+1
Resolved: approve minues of last meeting
<LarsG> https://www.w3.org/2017/dxwg/track/products/4
<LarsG> action-193?
<trackbot> action-193: Rob Atkinson to Move jmeter test suite to within w3c systems -- due 2018-09-05 -- OPEN
roba: this is still open but progress is being made
roba: list profiles support still to go
<LarsG> action-306?
<trackbot> action-306: Nicholas Car to Ask annette if #544 can be closed, else she should provide more detail -- due 2019-03-07 -- OPEN
<LarsG> ncar: underlying issue has been long closed
<LarsG> ... so we can close this action
<LarsG> close action-306
<trackbot> Closed action-306.
ACTION-306 is only being closed now since it was in the wrong ACTION list and not seen
<LarsG> action-358?
<trackbot> action-358: Rob Atkinson to to convene working session to co-develop common model to match link header data and alternates view requirements. -- due 2019-08-08 -- OPEN
roba: action still open
<LarsG> https://github.com/w3c/dxwg/issues/1017
LarsG: initiated by a question from TomB
<LarsG> Comment from Karen: https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Aug/0002.html
<LarsG> Comments from TomB: https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Aug/0003.html https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Aug/0004.html
As per discussion in the CNEG subgroup meeting 2019-08-29, the subgroup feels that if communities wish to use Conneg by Profile, then they must provide URIs for the things being conformed to (Profiles). Communities may choose not to do so but then they will not be able to use this specification.
(the above is proposed wording for a response in the GitHub Issue)
<roba> when using the proposed CNEG mechanisms it is up to each community to determine what a profile identifier means in terms of expected responses. If a URI points to an ambiguous resource with no clear conformance requirements then server may not be usefully predictable.
(the above is proposed wording for a response in the GitHub Issue)
<roba> the nature of the server response
The above response is in Issue 1071 (https://github.com/w3c/dxwg/issues/1017#issuecomment-526164813)
<LarsG> https://github.com/w3c/dxwg/wiki/Steps-to-Recommendation-2019
1. this proposal, to cater for tokens, does impact the IETF document - the token definition mechanism will need to be given there
2. servers may choose to implement tokens or not
3. if they do not, they have no further work to do (nothing to implement)
4. the motivation for catering for tokens is that existing profile negotiation systems (pyLDAPI, OAI-PMH, OGC Name Server) all use tokens
5. if we do not provide a token/URI linking mecahnism in the IETF doc, since the W3C doc is dependent on it, then we prevent those systems from being able to adhere to a formal specification
<LarsG> <The above points is about issue #290>
Action: LarsG to propose generalising syntax for the IETF doc to bypass hard requriement for token indicator
<trackbot> Created ACTION-362 - Propose generalising syntax for the ietf doc to bypass hard requriement for token indicator [on Lars G. Svensson - due 2019-09-05].