+1
<ncar> +1
roba: We need to discuss profile definition, too
<roba> +1
+1
<roba> +1
<ncar> +1
Resolved: accept minutes
Resolved: Approved minutes from last meeting
action-193?
<trackbot> action-193: Rob Atkinson to Move jmeter test suite to within w3c systems -- due 2018-09-05 -- OPEN
roba: No progress on 193
action-343?
<trackbot> action-343: Nicholas Car to Update qsa documentation with an equivalent to getcapabilities -- due 2019-07-11 -- OPEN
ncar: large update
… we might be able to circumvent this issue
… the link header can be the key here
… we need to give the ua a hint of the alternate views
… and that can be done through the link header
roba: Is it possible to create examples?
ncar: <describes the implementation proposal>
roba: this conflates 343 and 347...
… we'll leave 343 open until ncar makes a PR
action-347?
<trackbot> action-347: Rob Atkinson to Create new gh issue explaining the problem of redirects and refer to that issue in the wd -- due 2019-07-18 -- OPEN
roba: we'll handle this one together with 343
action-348?
<trackbot> action-348: Nicholas Car to Create pr with real examples to solve #287 -- due 2019-07-18 -- OPEN
ncar: still open
roba: Since conformance is a community issue it's for the community to clarify which URIs to use
ncar: is this only about conneg or about profile identification in general?
roba: if there are different profile definitions in one document
… we need different URIs within the document
… in order to identify the profiles properly
ncar: is this similar to the functional profiles defined in §2.1?
roba: No, it's about the data profiles used for conneg
… so can we agree that conneg works on data profiles
… and that there are functional profiles for how conneg works?
LarsG: +1
… but that doesn't answer '
… Tom's question.
roba: It's true that for conneg to work, we need distinct URIs
… for each profile. If there are no distinct URIs in the specification
… document, the community needs to invent some
… so that the URIs unambiguously identify profiles
… If the whole specification has only one URI,
… it's not unambiguous
<roba> If a specification is unambiguous about the requirements for conformance as a data profile then it only needs a single URI....
<roba> if there are multiple options defined in the specification which can be negotiated against then these must be unambiguously identified with distinct URIs
<roba> conneg-by-aP provides no mechanism for describing which arbitrary part of a specification is being conformed to .
<ncar> if there are multiple options or parts of or within a specification which may be considered suitable for being conformed to then these must be unambiguously identified with distinct URIs and thus can be negotiated with for content
LarsG: goes in the right direction but needs some word-smithing
… discussion will be in GH #1017
… once that's resolved, we can answer Tom
Action: LarsG to review Antoine's comments and check if the 3PWD addresses them all
<trackbot> Created ACTION-351 - Review antoine's comments and check if the 3pwd addresses them all [on Lars G. Svensson - due 2019-08-01].
ncar: sees a problem since the new definitions are about "data profiles"
… while conneg talks about "profiles"
… has made some PRs to reflect this in conneg, prof etc.
roba: not much of an issue to conneg since that's about data profiles
… prof, however, is also about functional profiles
… data profiles are narrower than profiles
ncar: we need to ensure that the definition doesn't remove context from the document
roba: PROF will define profile as it always has and then add the definition of data profile
ncar: has split the spec of profile in two parts in the current PR
Succeeded: s/part of an arbitratry specification/arbitrary part of a specification/