Content for the Abstract Model section

[nicholascar]

This issue is for the Abstract Model Section in the Content Negotiation by Profile document.

[nicholascar]

How should we define a list of actions (methods?) in the abstract that a client and server must/may etc implement? What formal function description languages are available? Should it be something like this:

client:
    function request_list_profiles_for_resource:
        a client requests the available profiles for a resource

    function request_list_profiles_tokens_for_resource:
        a client requests the token/URI mappings for a resource

    function get_profile:
        a client requests a profile by preference list from a server

server:
    function respond_list_profiles_for_resource:
        a server sends the list of profiles for a resource to a client

    function respond_list_profiles_tokens_for_resource:
        a server sends the list of token/URI mappings for a resource to client

    function send_profile
        a server responds to a get_profile request with either a specific profile or a default profile if the requested profile(s) is unavailable

[larsgsvensson]

Definitions for the "Abstract Model" section extracted from the I-D

The I-D does not define much terminology. It does use the following:

• profile: "a document that expresses the structural and/or semantic constraints of other documents"
• application profile: "schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application" Rachel & Heery, 2000
• alternate representation: (no definition)
• preferred profile: the profile a user agent would prefer the returned data to adhere to (not formally defined, but that's the gist of it)

This is for ACTION-233

[larsgsvensson]

I don't quite understand the function get_profile. If a client calls the get_profile function, is that a request for the actual profile or for a resource that conforms to a specific profile?

I also don't understand the server functions. If we say that profile negotiation is a request-/response-pattern, I would expect that the client calls a function and that what is here modeled as server functions are simply the return values.

[nicholascar]

I admit @larsgsvensson that this is far from polished! I tried defining functions above (badly) in order to separate from the HTTP client/server request/response directly but perhaps this is just confusing since all of our realisations (HTTP, QSA and perhaps REST) are all client/server-based.

I have changed get_profile to get_profile_of_resource for you first point and, for the second, I've renamed the pairs to requests/response.

• client request list_profiles_for_resource:
  • a client requests the available profiles for a resource
• server response list_profiles_for_resource:
  • a server sends the list of profiles for a resource to a client
• client request list_profile_tokens_for_resource:
  • a client requests the token/URI mappings for a resource
• server response list_profiles_tokens_for_resource:
  • a server sends the list of token/URI mappings for a resource to client
• client request get_resource_according_to_profile:
  • a client requests a profile by preference list from a server
• server response get_resource_according_to_profile:
  • a server responds with either a specific profile or a default profile if the requested profile(s) is/are unavailable

I am most keen now to determine whether if in concepts these are all of the request/response pairs we are dealing with or if have we missed some? I admit that two of these (the token ones) may not need to be implemented by an HTTP realisation and that a REST realisation won't be able to do things like requesting a profile by preference list.

[rob-metalinkage]

I'm not sure the model is get_resource_according_to_profile(resource, profile)

so much as get_resource(resource, prefs) where prefs is a list of aspect: [ordered list of options]

[rob-metalinkage]

We should perhaps look at the style of this document and try to match it?

https://www.w3.org/TR/swbp-vocab-pub/#recipe6

[nicholascar]

Sections 1.2 (Compliance), 1.2 (Notation Conventions) added to support Section 5 (Abstract Model) to which content has been added: https://raw.githack.com/w3c/dxwg/conneg-doc/conneg-by-ap/index.html (branch, no PR yet).

Sorry Lars, I had typed this all out before reading your comments above (didn't expect them now at this time of night for you). Will read the SWBP you link to next.

[larsgsvensson]

Thanks for the updates @nicholascar. I'm not looking at the notational conventions (yet) but more at the general pattern and I'm pretty sure that we should focus on client-side functions with server-side responses since I we don't have a use case where the server initiates the conversation.

[nicholascar]

Due for closing as we have a section with content. Other issues can be raised for improvements.

[larsgsvensson]

Closed in CNEG meeting 2018-11-07

[larsgsvensson]

Removed label since the issue is closed