W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > November 2018

[dxwg] Jaroslav's conneg doc edits

From: Nicholas Car via GitHub <sysbot+gh@w3.org>
Date: Tue, 13 Nov 2018 21:17:56 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issues.opened-380427753-1542143875-sysbot+gh@w3.org>
nicholascar has just created a new issue for https://github.com/w3c/dxwg:

== Jaroslav's conneg doc edits ==
From: https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Nov/0400.html

> "When a non-existent or unsupported profile is requested, a server returns default content"

- clarify what is meant here:
    - non-existent: profile identifier not understood by server?
    - unsupported: generally well known profile applicable to variety of contents that happens to not be supported by given server?
        - this may imply there will be registry of profiles, like IANA offers for Media Types. But this is excluded later on:
        "There is no proposal yet to create a central register of profiles as this is thought by the authors to be un-sustainable
        in the long-term, given the likely numbers of profiles to be established."  
- section 2, definitions
    "profile", is ambiguous, "constraints on one or more identified base specifications",
    i.e. profiles constraint specifications or do they in fact reuse and "specialise clauses 
    from one or more base specifications" in order  to express constraints on content?

    "token", a short name identifying something (profile) --> better "alias"?

- section 5.1 Context
    "In some cases, a server may have to make a request of a client and receive a response."
    - which are these cases, is this relevant to mention while unclear?

    "These aspects are to be treated independently so content negotiation for a resource involving
    negotiation by profile and potentially multiple other aspects of a resource will not affect each other."

    - this is not the case, Media Type and Profile may and will inter-depend, only one set of Media types
    may be available for a particular profile, another set for a different profile. All these content
    constraints interact and are not independent of each other. 

- section 5.2. Requests and Responses
    - is there a reason why invoking "list profiles" can't deliver information of "list profiles tokens", making it obsolete?
    - response to "get resource by profile" should indicate the profile applied (the requested or the default one)

- section Using a HTTP Link header field
    - Example 2, Using a Link-header to point list available profiles
    - the "Content-Location" does not seem to be used in accordance to HTTP spec, since referring to profile and not to a particular resource representation
        - https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14
    - same holds for link relation, since performing a head on a resource (and not a profile) should not it read:
        - <link rel="profile" .. >?

- section 6.2.1 list profiles
    - I would not suggest reusing the same query parameter for identifying individual profiles (_profile=URI) *and* requesting a list of them (_profile=list)
    - a dedicated parameter may by used (_list), e.g. allowing for listing of profile (_list=profile) or media type (_list=media-type)

- section A.1 Requirements
    - is there a reason of stating CONNEG requirements separate from other (profile-related) requirements outside of the UCR document?

Please view or discuss this issue at https://github.com/w3c/dxwg/issues/569 using your GitHub account
Received on Tuesday, 13 November 2018 21:17:58 UTC

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