Re: [dxwg] Antoine's conneg doc edits (#575)

Issue 4 remains. The IETF doc is still mentioned in related work, which is misleading. It's not like other related work at all, since it's rather a 'companion' document. I reckon the opening paragraph in the related work section mentions it will be removed, so maybe I could leave with keeping IETF mentioned there for the time being. But then it's confusing as this is presented as regular text. It would be better to put it as a formalized editors' note (in green). And it seems it could do with an update about what's happening with the IETF. I believe the same text has been here for quite a while. 

Issues 5, 6, 7 have been handled.

Issue 11 also remain. I see in the abstract model [6.3.2 get resource by profile](https://w3c.github.io/dxwg/conneg-by-ap/#getresourcebyprofile) still says "preference expressed in a functional profile-specific ordering" while [7.1.2 get resource by profile](https://w3c.github.io/dxwg/conneg-by-ap/#http-getresourcebyprofile) still relies on "indicate preferences by using quality indicators (q-values)".
q-values are not exactly equivalent to an ordering. If just because (as @larsgsvensson  acknowledged in #591) q-values can have ties. So one can say the HTTP Headers realization is at odds with the abstract model. Is there any explanation about this in the new draft?

Issue 15 is still open. The content has changed, but I think that (at least) example 8 and 9 in [7.1.1](https://w3c.github.io/dxwg/conneg-by-ap/#http-listprofiles) as well as example 11 in [7.1.2](https://w3c.github.io/dxwg/conneg-by-ap/#http-getresourcebyprofile) are not compatible with Linked Data style Conneg. I repeat what I said about this: these examples are at odds with the conneg recipes derived from Http-range-14. In RDF statements, the 'most interesting' URIs are URIs of non-information resources. These non-information resources are expected to first be de-referenced to the URI of a representation via a 303-redirect. That URI is then served with a 200. There are of course cases where the pattern of the current examples will be the right one. But now the text really says that the simple 200 pattern is the one expected ("a request/response pair would look as per example [X]").

Issue 16 has been handled. I guess one may make comments on some sentences, but to me it's clearer now, what kind of motivation you have for QSA.
Issues 17 has been handled too.

Issue 18 remains, and maybe is worse. The wording I was refering to in the old 6.2 (now [7.2](https://w3c.github.io/dxwg/conneg-by-ap/#qsa)) has been changed. And now [7.2.1.1](https://w3c.github.io/dxwg/conneg-by-ap/#qsa-uri) introduces media type QSA as an example of including other QSAs:

To demonstrate an acceptable inclusion, if the client using the URI in Example 12 wished to indicate a preference for the content of the request to be serialised as RDF, according to the Turtle [TURTLE] specification, it could use the IANA Media Types list's token for Turtle which is text/tur
tle and formulate the URI as per Example 13 which is accordance with URI formulation requirements [RFC3986].
That is fine, but then why does the rest of the spec continues to say things about the _media_type QSA, even quite formal recommendations about them, like "SHOULD use _mediatype to indicate a resource representation's Media Type" in [7.2.1.2](https://w3c.github.io/dxwg/conneg-by-ap/#qsa-key-naming)  ?

This again hints that media type is a key aspect of the realization, while it's not. I don't see why a spec about getting profile-specific representation would blur the picture by also discussing media types quite extensively. It's probably fine to keep the _media_type QSA in some examples, if it helps making some points, but frankly I believe there is too much, now.

Issue 19 seems to handled, or maybe it's obsolete now as I don't see any example that looks like the one I was refering to ("GET /a/resource?_profile=aaa,bbb,ccc HTTP/1.1")

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

Received on Saturday, 7 September 2019 15:27:54 UTC