Hello folks,
Just spotted this discussion. If you find it useful, the TAB wrote a white paper on keywords in 2014 (so it may be due for a review). "Keyword Guidelines for OASIS Specifications and Standards" is at https://www.oasis-open.org/policies-guidelines/keyword-guidelines.
Best,
/chet
On Fri, Jan 12, 2018 at 9:12 AM, Mr. Stefan Hagen <> wrote:
Thank you Katrina!
for not letting me stand there alone in that language corner :-)
Sometimes we are reminded, that the world is not switching to English,
and the British and Americans do not have to fight against or for
extra "u" letters and the like or the order of er vs. re in word endings
or what exactly expiry means ...
*but* the world is forming a new language starting from English! ...
and as spec writers introduce meta languages like the MUST et al.
on top.
In OASIS and IETF we use RFC 2119 as updated by RFC 8174 - or
like every fresh workproduct will have in the boilderplate / frontmatter:
"""
1.2 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in
this document are to be interpreted as described in [RFC2119] and [RFC8174].
"""
esp. the "[] only UPPERCASE usage of the key words have the defined
special meanings." part in RFC8174 emphasizes, that this is not
natural language.
I always understood this as highlighting or tagging with a code.
Clear understanding for implementers in exactly these situation
where (we) the spec writers point out something via MUST, SHOULD
or MAY justifies breaking the "reading flow".
Could we maybe also try to white instead of blacklist where possible
(which would help the reader a lot, as every "not" or "NOT" comes as
an extra evaluation task :-)
For me a spec that utilizes more than these three dimensions (MUST,
SHOULD, MAY) is suspicious at least provoking the question if another
spec staying with these three terms would lead to better interoperable
and conforming implementations.
I would suggest to focus on what we want and serve the OASIS rules,
as OASIS is a public accepted submitter to ISO and with OData as an
example, we had no trouble after we made the OASIS Standard stage,
to also submit unchanged to ISO, fill in a form, where OASIS stated,
that the TC would continue to work on future versions, and then we
waited for the many months election period and the bunch of OData
standards was concat and wrapped as i and is now an ISO standard -
for free.
And much clearer in my opinion as with some IEEE -> ISO standards,
where to me accessibility and status of the originating IEEE standards
is not always clear, the OASIS OData standard documents are still the
accepted, and best navigateable form to "use" it ...
If you guys with native English reading capabilities perceive hurt
when reading clumsy UPPERCASED terms (MUST vs. SHALL) like Laurence
explained very well, IMO we should find a way that is good for the
group, easy to read and understand for all.
What I would be very reluctant to follow are below (or in other
mails of this thread) noted specific differentiations in effective
meaning of (RFC 2119 synonyms) i.e. I want to preserve:
MUST == REQUIRED == SHALL
relations ...
I wrote this in a (small) browser rendered html "textarea", so
albeit I wrote this mail a few times before sending, some hard to
understand text may have slipped through, and if so, I already feel
sorry for that.
All the best,
Stefan.
On 12/01/18 06:44, O'Neil, Yekaterina Tsipenyuk wrote:
> As a non-native speaker, I have to say I had to pause for a second to think about what the proposal of changing SHOULD to SHALL means. I did infer the meaning of the change correctly, but I think it was mainly due to the fact that the attention was drawn to making this change. That is, if I was just reading the final version of the spec, I would have not picked up on the connotation.
>
> I think the options listed below would not cause a confusion for me though.
>
> k
>
> -----Original Message-----
> From: [mailto:] On Behalf Of Michael Fanning
> Sent: Thursday, January 11, 2018 10:40 AM
> To: David Keaton <>; Larry Golding (Comcast) <>; 'Mr. Stefan Hagen' <>;
> Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications"
>
> Hm, interesting. Use of MUST in our case certainly doesn't conform to ISO's notion of it.
>
> I see the following list of ISO acceptable alternates to SHALL NOT. Not sure whether any of these meet Stefan's criteria of being more accessible to non-native EN speakers.
>
> is not allowed [permitted] [acceptable] [permissible] is required to be not is required that … be not is not to be need not do not
>
> Again, back to this specific issue. I wonder if we shouldn't inject a note that amplifies on the spec language (which refers to SHALL NOT). We'd want to emphasize that it is really not acceptable for SARIF to contain executable code but that due to lack of controls on user-input and/or guaranteeing the integrity of a SARIF file and the dangers of failure to sanitize, consumers can't assume that the spec has been met for this case. It is not acceptable for producers to inject executable code into SARIF markdown. It is not acceptable for consumers to fail to sanitize.
> ... [ -- - 8< - -- ]
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
