There should be a way to look up additional information about a profile - this may be machine readable for run-time mediation or used to develop or configure a client [ID2] (5.2)

[nicholascar]

Entered from Google Doc

What kinds of information? Can we clarify this?

[aisaac]

Apparently there's a new wording: "There should be a way to look up additional information about a profile - this may be machine readable for run-time mediation or used to develop or configure a client "

[kcoyle]

Hmmm. That new wording addresses "way" but not "additional".

Here's what ID2 says:

"In order to inform clients that a representation conforms to a certain profile, servers should be able to explicitly indicate which profile(s) a response conforms to. This then allows the client to make the additional structural and/or semantic interpretations that are allowed within that profile. "

So how about:

"There should be a way to look up information that can be used to determine which profile(s) conform to the request - this may be machine readable for run-time mediation or used to develop or configure a client "

[nicholascar]

...which profile(s) conform to the request...

I don’t think this is possible! Responses may conform to profiles or profiles may conform to things but a request cannot. A request is usually something like:

GET http://example.com/resource/a

perhaps with parameters such as HTTP headers or Query String Arguments.

Do you mean “...which profile-conformant representations of a resource may be requested...”?

[aisaac]

Whatever the result of this discussion is, I'm changing the title of the requirement from "There should be a way for a client to look up additional information about a profile. (What kinds of information? Can we clarify this?) [ID2] (5.2)" to "There should be a way to look up additional information about a profile - this may be machine readable for run-time mediation or used to develop or configure a client"

I was searching for more detail about ID2 in the google doc (https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/) and then I found a note from myself (July 3) saying the the re-wording was made by the Conneg sub-group, and approved by the plenary group. So I think it's not up for discussion now, even if of course the meat of requirement can still be discussed here... Sorry I had missed it as it was not in the 'requirement' section of the doc.

[kcoyle]

@nicholascar The use case was written by Ruben and I'll admit that it never made sense to me - I just assumed it would make sense to others. Unfortunately Ruben isn't around and we're kind of stuck with the use case, so maybe it needs some re-wording? Could you read through it and see what does and doesn't make sense? Thanks!

[RubenVerborgh]

@kcoyle I'm around when tagged 🙂

[RubenVerborgh]

So the idea is as follows.

A profile has a certain identifier, let's say MyAppProfile. Some clients will already be preprogrammed for MyAppProfile. So if they see MyAppProfile, they will know what to expect.

Other clients will not know about MyAppProfile. So they need learn more about MyAppProfile. For instance, it might be that MyAppProfile is actually compatible with MyOtherProfile, which might help them. Or they might find a document clarifying the structure of MyAppProfile, which might also help them.

This requirement says that we need to add a mechanism for a client to go from MyAppProfile to "more information" about MyAppProfile.

It was worded this way because I do not think DXWG should specify the structure or definition of that "more information", only the mechanism to look it up.

---

The above might still be very abstract, but that's because I wrote it as a problem, not as a solution. When phrased as a solution, thing will likely become much clearer.

A possible solution is:

• profile identifiers are HTTP URLs
• the HTTP URLs need to be dereferenceable
  • i.e., when you perform a GET on the profile URL, you receive more information about the profile
• DXWG does not specify the format of the returned document
  • only that such a document can be retrieved by this mechanism

[nicholascar]

I understand this requirement as @RubenVerborgh explains it so shouldn’t have a problem dealing with this.

Not yet sure where the mechanism will be detailed but presume in the Conneg doc but this is an extension to current scope. That’s fine: it just indicates this Req isn’t yet covered in the FPWD so we need to make sure it gets noted there.

The need and outline of a solution could be mentioned in Guidance too but the mechanics are a Conneg thing as per Ruben’s phrasing.

[RubenVerborgh]

I think this can be easily covered in https://w3c.github.io/dxwg/conneg-by-ap/ if we say that a profile URI SHOULD be an HTTP(S) URL, and that it SHOULD be dereferenceable.

[aisaac]

@nicholascar I am puzzled: isn't the goal of PROF precisely to capture the 'more information about the profile'? I mean, maybe we don't get all the things that @RubenVerborgh describes here but the mechanism is there (and in the use case ID2 didn't require more). I'm keen on leaving this requirement tagged as 'profile-guidance' to help making the connection clear, that this is a requirement that needs two aspects of our work.

[nicholascar]

De-tagging as profile-negotiation as dealt with by its point of view