- From: Newton Calegari <newton@nic.br>
- Date: Wed, 20 May 2015 11:17:44 -0300
- To: yaso@nic.br
- Cc: public-dwbp-wg@w3.org
- Message-Id: <5F3C1F89-F81C-4934-A3CF-2A623C2EAC10@nic.br>
+1 for removing them all Should we use the rating system in the next version that is going to be published? Newton > Em 19/05/2015, à(s) 10:32, yaso@nic.br escreveu: > > +1 > > On 05/19/2015 03:45 AM, Annette Greiner wrote: >> +1 >> >> On May 18, 2015, at 2:58 PM, Bernadette Farias Lóscio <bfl@cin.ufpe.br> wrote: >> >>> 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 Wednesday, 20 May 2015 14:18:25 UTC