- From: Bernadette Farias Lóscio <bfl@cin.ufpe.br>
- Date: Mon, 18 May 2015 18:58:58 -0300
- To: Annette Greiner <amgreiner@lbl.gov>
- Cc: Joao Paulo Almeida <jpalmeida@ieee.org>, Phil Archer <phila@w3.org>, "yaso@nic.br" <yaso@nic.br>, "public-dwbp-wg@w3.org" <public-dwbp-wg@w3.org>
- Message-ID: <CANx1PzwwwfCZJKv0gU77D69-C23wB6hL9Nda_2=vHPo29ucOdQ@mail.gmail.com>
Dear all, I'd like to propose the removal of the RFC keywords from the DWBP document. Cheers, Bernadette 2015-05-18 18:17 GMT-03:00 Bernadette Farias Lóscio <bfl@cin.ufpe.br>: > +1 Annette! > > 2015-05-18 18:07 GMT-03:00 Annette Greiner <amgreiner@lbl.gov>: > > Take a look at how WCAG does it [1]. They don’t use RFC2119 keywords. >> Instead, they add “(Level A)”, “(Level AA)”, etc. Where terms like “must” >> and “should” arise in the text, they are treated as they are used in plain >> English. That obviates the awkwardness of trying to make keywords that were >> developed for specifying a technology work for best practices documents. In >> my view, using RFC2119 keywords makes our documents appear to be imposing >> actual requirements, which I think is potentially confusing for readers. It >> suggests that failure to follow a given BP will prevent users from being >> able to access the data. The nice thing about going without the keywords is >> that it means people can claim a lower level of conformance and still feel >> good, whereas people who meet the higher standard can claim that and feel >> even better. We wouldn't need to compromise on what we expect from people, >> and we could provide some stretch goals. >> >> One particular section of that RFC particularly bothers me in considering >> its use for best practices. It’s the following: >> >> 6. Guidance in the use of these Imperatives >> >> Imperatives of the type defined in this memo must be used with care >> and sparingly. In particular, they MUST only be used where it is >> actually required for interoperation or to limit behavior which has >> potential for causing harm (e.g., limiting retransmisssions) For >> example, they must not be used to try to impose a particular method >> on implementors where the method is not required for >> interoperability. [2] >> >> [1] http://www.w3.org/TR/WCAG20/ >> [2] https://www.ietf.org/rfc/rfc2119.txt >> >> -- >> Annette Greiner >> NERSC Data and Analytics Services >> Lawrence Berkeley National Laboratory >> 510-495-2935 >> >> On May 18, 2015, at 12:09 PM, Joao Paulo Almeida <jpalmeida@ieee.org> >> wrote: >> >> Hi Annette, >> >> That just changes the use of the normative statements a bit. >> >> I proposed to interpret the normative statements in the following way: if >> you claim conformance, you MUST, ... >> >> What you are proposing sounds like: if you claim conformance to level X, >> you MUST, ... >> >> regards, >> João Paulo >> >> >> >> On Mon, May 18, 2015 at 3:32 PM, Annette Greiner <amgreiner@lbl.gov> >> wrote: >> >>> We’ve had an idea at various times to assign a rating system, something >>> like the five stars but different enough to avoid confusion. I still think >>> that’s the best way to deal with this issue. It enables a publisher of data >>> to claim a concrete level of compliance, much like the WCAG. >>> -Annette >>> -- >>> Annette Greiner >>> NERSC Data and Analytics Services >>> Lawrence Berkeley National Laboratory >>> 510-495-2935 >>> >>> On May 18, 2015, at 8:17 AM, Phil Archer <phila@w3.org> wrote: >>> >>> > The issue is open in tracker so I'm taking it as open - but if we're >>> taking them out (and I think we are too) then some of the intro matter and >>> the template need updating. >>> > >>> > Phil >>> > >>> > On 18/05/2015 16:03, yaso@nic.br wrote: >>> >> I thought we had an agreement on this: >>> >> >>> >> "An alternative would be not to include any RFC2119 keywords at all" >>> >> >>> >> I ran trough the logs and couldn't find nothing against not using the >>> >> RFC2119 keywords at the document. Furthermore, we talked at the F2F >>> >> about the translation to Portuguese problem with the keywords. There >>> was >>> >> another decision on that? >>> >> >>> >> >>> >> yaso >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On 05/18/2015 11:53 AM, Phil Archer wrote: >>> >>> Dear all, >>> >>> >>> >>> The BP editors have been working hard and have made a number of what >>> I >>> >>> think are big steps forward with the doc. >>> >>> >>> >>> But Issue-146 remains unresolved: what is normative in a BP? >>> >>> >>> >>> Take our old favourite first BP >>> >>> http://w3c.github.io/dwbp/bp.html#ProvideMetadata that says: >>> >>> >>> >>> Metadata MUST be provided for both human users and computer >>> applications >>> >>> >>> >>> I doubt anyone here will disagree with this statement, but is it >>> right >>> >>> to make this the normative part of the BP? And, if so, are we right >>> to >>> >>> use the RFC2119 MUST? >>> >>> >>> >>> Take a less clear cut example: >>> >>> http://w3c.github.io/dwbp/bp.html#MultipleFormats that says: >>> >>> >>> >>> Data SHOULD be available in multiple data formats. >>> >>> >>> >>> Really? >>> >>> >>> >>> SHOULD is "comply or explain" - i.e. you'd better have a very good >>> >>> reason not to provide data in multiple formats so I might argue one >>> day >>> >>> that this should be a MAY. What does MAY mean? From the infamous >>> RFC2119: >>> >>> >>> >>> "This word, or the adjective "OPTIONAL", mean that an item is >>> >>> truly optional. One vendor may choose to include the item >>> because a >>> >>> particular marketplace requires it or because the vendor feels >>> that >>> >>> it enhances the product while another vendor may omit the same >>> item." >>> >>> >>> >>> (I've omitted the rest of the definition but this is the essence of >>> it). >>> >>> >>> >>> Suppose the WG agrees and this BP now becomes: >>> >>> >>> >>> "Data MAY be available in multiple data formats." >>> >>> >>> >>> Which doesn't really convey in a single sentence what we mean. We >>> might >>> >>> end up with >>> >>> >>> >>> "Publishers are encouraged to make data available in multiple formats >>> >>> (OPTIONAL)" >>> >>> >>> >>> i.e. re-word the normative line to fit in with the definition of the >>> >>> relevant RFC2119 keyword. >>> >>> >>> >>> An alternative would be not to include any RFC2119 keywords at all. >>> I'm >>> >>> easy either way - I can see arguments for and against including these >>> >>> keywords - but it remains an open issue that I think we owe it to the >>> >>> editors to decide what to do. >>> >>> >>> >>> Phil. >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> > >>> > -- >>> > >>> > >>> > Phil Archer >>> > W3C Data Activity Lead >>> > http://www.w3.org/2013/data/ >>> > >>> > http://philarcher.org >>> > +44 (0)7887 767755 >>> > @philarcher1 >>> > >>> >>> >>> >> >> > > > -- > Bernadette Farias Lóscio > Centro de Informática > Universidade Federal de Pernambuco - UFPE, Brazil > > ---------------------------------------------------------------------------- > -- Bernadette Farias Lóscio Centro de Informática Universidade Federal de Pernambuco - UFPE, Brazil ----------------------------------------------------------------------------
Received on Monday, 18 May 2015 21:59:47 UTC