Hi Mike, The usual convention is if you use the words in the RFC 2119 sense, they're upper case (and you'd include a line saying this somewhere). If they're lower case as in your example below, I would not interpret it as an RFC 2119 key word. Conversely, your later sentence might then be rephrased as "If the representation is ambiguous [..] the Unparser MUST flag a schema definition error" - or some such. Maybe even "representation properties MAY be used to eliminate the ambiguity" [in order to emphasise that this is optional] Regards --jens On 30/09/2019 17:34, Mike Beckerle wrote:
In studying Tracker 304 https://redmine.ogf.org/issues/304 I have found that there are many uses of words like must and should, which are not specifically in accord with the notions of RFC 2119, because they are not involved in statements about requirements.
For example, in section 2.3.1.1
Usually, the behavior of the unparser is symmetric to the behavior of the parser; however, there are cases where the DFDL schema will accept several equivalent representations for the same logical data. In this case it would be ambiguous which of these equivalent representations should be produced by the unparser. The DFDL standard contains representation properties which are used to eliminate this ambiguity. It is a schema definition error if a DFDL schema is being used to unparse data and there is any ambiguity about the representation.
We can either ignore such issues, because the context doesn't require us to consider this a requirement statement, or reword so as to avoid RFC2119 terms. I am not sure it is worth changing this prose in all the places where this sort of thing happens. The word 'should' is less problematic than the word 'must' of which there are hundreds of occurrences.
Thoughts?
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com <http://www.tresys.com> Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg