Minutes from the CNEG meeting 2018-06-20

Yesterday we had a very productive meeting in the CNEG subgroup.

We decided to propose text changes to the following requirements (numbering as in the google doc on profile requirements [1]):

3) "Requirement: 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)"

Proposed rewording:

"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".

5) "Requirement: a profile offered by a service must be discoverable through a machine-readable graph of metadata that describes what is offered and how to invoke the offered profiles.  [ID5] (5.5)"

After discussion our resolution was that this is really two requirements (discovery and invocation of profiles) and that those are already covered in 2 and 3. Here we propose that this requirement is removed as a duplicate.

6) "Requirement: Invocation of a profile may be by profile name, a schema choice, an encoding, and/or a language. (schema? And assume that encoding is type as in type="application/xml".) [ID5] (5.5)"

Here we propose that the suggested replacement text is accepted with a minor change:

" When requesting a representation, a client must be able to specify which profile it prefers the representation to adhere to. This information about the requested profile is not a replacement for content type (e. g. application/xml), language (e. g. zh-Hant) or any other negotiated dimension of the representation."

7) "Requirement There needs to be metadata about the views provided by profiles (“named collections of properties”) that can included in a http header [ID5] (5.5)"

We propose that this is reworded to

"Requirement: A short token to specify a profile may be used as long as there is a discoverable mapping from it to the profile's identifying URI"

and accepted as a requirement

4) "Requirement: A profile can be modular, with a given response made up of more than one module. A server can indicate that a response conforms to multiple, modular profiles.  [ID3] (5.3) [conneg] [profile]"

This is an important one that needs more discussion, particularly considering Antoine's suggestion "some data may conform to several profiles at once” and that we should remove modular". We decided to move this to an email discussion (perhaps a github issue does the trick, too).

Regarding the prioritisation of the conneg requirements, we consider all of those discussed to be in scope and couldn't really say that one of them is more important than the other.

Finally we discussed what the process is to get the updated requirements into the UCR. Our proposed process would be that once the plenary has decided to accept a requirement, there will be an action on someone (the "requirement owner"?) to submit pull requests to the UCR editors. Is this how it's supposed to work or do we need to discuss that in the plenary? (ACTION-131)

Full meeting minutes at [2].

[1] https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit#

[2] https://www.w3.org/2018/06/20-dxwgcneg-minutes.html

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Adickesallee 1
60322 Frankfurt am Main
Telefon: +49 69 1525-1752
Telefax: +49 69 1525-1799

Received on Thursday, 21 June 2018 09:28:39 UTC