Re: What is normative?

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