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

FW: Conneg poll

From: Nicholas Car <nicholas.car@surroundaustralia.com>
Date: Tue, 24 Sep 2019 21:04:32 +0000
To: DXWG WG List <public-dxwg-wg@w3.org>
CC: "lars.svensson@web.de" <lars.svensson@web.de>, Rob Atkinson <rob@metalinkage.com.au>, Robert Sanderson <azaroth42@gmail.com>
Message-ID: <TY2PR0101MB25096D9462F6F56896A8FFCCA2840@TY2PR0101MB2509.apcprd01.prod.exchangelabs.com>
Forwarding an on-going conversation about issues with the Conneg document moving to CR to the DXWG mailing list.


From: Robert Sanderson <azaroth42@gmail.com>
Date: Wednesday, 25 September 2019 at 6:36 am
To: "lars.svensson@web.de" <lars.svensson@web.de>
Cc: Rob Atkinson <rob@metalinkage.com.au>, Nick Car <nicholas.car@surroundaustralia.com>
Subject: Re: Conneg poll

Err, the former is preferable, obviously :)


On Tue, Sep 24, 2019 at 1:35 PM Robert Sanderson <azaroth42@gmail.com<mailto:azaroth42@gmail.com>> wrote:

I have two objections, one procedural and one technical:

The procedural objection is that the document contains Issue blocks such as in https://w3c.github.io/dxwg/conneg-by-ap/#profileid
A document that contains unresolved issues is not ready for CR, regardless of the technical content. If I were the W3M team, I would immediately reject the transition request as CR documents should be ready to be implemented with all of the issues resolved.  If there are no findings during CR, then apart from typos or other minor editorial changes on that magnitude, the document should be ready for TR. This document is not in that state.

For the technical URI issue, the problem is that the Accept-Profile header content model is ambiguous, as there isn't a way to delimit URIs from the header parameters. The example in section 7.1.2 is:

This is one URI -- there's no way to know that the ; and beyond is not part of the urn.
The URIs need to be delimited in the same way as for Link headers.

My attack is simply to define a profile with ";q=1.0" as a part of the URI, and then it will take precedence over other profiles.

The issue can be addressed before CR, or it can be addressed during CR prompting a new CR period. I think the latter is preferable!


On Tue, Sep 24, 2019 at 6:05 AM <lars.svensson@web.de<mailto:lars.svensson@web.de>> wrote:
Piggy-backing on Nick's questions:

I cannot find a single URI with ";q=" in it... Can you point me to that specific location (I think it must be an error...).

Or do you mean in example 13 [1] where it says

Accept-Profile: urn:example:profile:x;q=1.0,urn:example:profile:y;q=0.6

In those cases the ";q=" is not part or the URI, but are q-values similar to

Accept: text/turtle;q=0.8, application/xml;q=0.5

[1] https://w3c.github.io/dxwg/conneg-by-ap/#eg-http-get



> Gesendet: Dienstag, 24. September 2019 um 14:58 Uhr
> Von: "Nicholas Car" <nicholas.car@surroundaustralia.com<mailto:nicholas.car@surroundaustralia.com>>
> An: azaroth42@gmail.com<mailto:azaroth42@gmail.com>
> Cc: lars.svensson@web.de<mailto:lars.svensson@web.de>, rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>
> Betreff: Conneg poll
> Hi Rob,
> In the Conneg to CR poll you wrote:
> > There are still issue blocks saying "to be discussed", there are still issues with the content negotiation approach that make the requests ambiguous (for example a URI with ";q=" in it), and the token approach is still under-motivated.
> As you note, there’s no time left now really so I fear that your objection - the only ‘no’ - will ensure there is no concerns us in 7 hours time, when we have to vote, and thus, is consensus is required for us to proceed, the specification will not make it to a Recommendation.
> How strongly do you feel about your points?
> The removal of the use of ;q= would be, I think, editorial since examples are not normative. Also, we do not include normative requirements ;q= use so if it’s in their incorrectly or unhelpfully then removing it doesn’t change any normative content even if it wasn’t in an example.
> You also said the token approach is under motivated. If so, then this is our representation issue in the document: Rob A and I both have legacy systems that use tokens that we wish to “wrap” with Conneg and, without token support, implementing this spec becomes unviable for us.
> Can you perhaps agree to allow us to proceed to CR to then let us find implementation evidence for the token use? (sneak peak: we have our two implementations and they are independent - we’ve never collaborated on them and they both existed before this WG!).
> I have to head to bed now before the plenary vote so I won’t see any answer you make here before the plenary unfortunately.
> Thanks,
> Nick
> —
> Nicholas Car
> Data Systems Architect
> SURROUND Australia
> 0477 560 177
> nicholas.car@surroundaustralia.com<mailto:nicholas.car@surroundaustralia.com>

Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049

Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049
Received on Tuesday, 24 September 2019 21:04:59 UTC

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