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

Re: Minutes from the CNEG meeting 2018-06-20

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Fri, 22 Jun 2018 10:00:46 +1000
Message-ID: <CACfF9LyEucqfXKGMKmPFiaLt4oSc5_W9xLuM3Yzvy9zhsws1fA@mail.gmail.com>
To: kcoyle@kcoyle.net
Cc: public-dxwg-wg@w3.org
As a UCR editor, the experience of leaving too much non-editorial work to
the editors - such as extracting requirements, means the group gets left
behind and we end up belatedly revisiting the whole process. Its much
better for the group assign actions to other people to generate PRs the
editors can review. We should be checking the content matches the group's
decisions and is well formed and appropriately cross-linked.

Rob


On Fri, 22 Jun 2018 at 00:47 Karen Coyle <kcoyle@kcoyle.net> wrote:

> Thanks for all of this. I've added suggested wordings to next week's
> agenda, where appropriate. As for #4 about modularity, I do think that
> this could benefit from a github discussion, so please create an issue
> and we can link to it.
>
> The UCR group should comment about the procedure for making the changes
> in the UCR document, and whether your suggestion of pull requests is the
> best way to go.
>
> kc
>
> On 6/21/18 2:28 AM, Svensson, Lars wrote:
> > 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 ***
> >
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
>
>
Received on Friday, 22 June 2018 00:01:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:44 UTC