OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (EMERGENCY-94) TEP 1.1 - TAB-1313: Conflicting definitions of "REQUIRED"


     [ https://issues.oasis-open.org/browse/EMERGENCY-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patti Aymond updated EMERGENCY-94:
----------------------------------

    Resolution: Leave notation as is. This notation is used consistently across the suite of EDXL standards for clarity. The EM-TC disagrees that these definitions are at odds.  (was: Leave notation as is, but change semicolon to colon in data dictionary. This notation is used consistently across the suite of EDXL standards for clarity. The EM-TC disagrees that these definitions are at odds.)

> TEP 1.1 - TAB-1313: Conflicting definitions of "REQUIRED"
> ---------------------------------------------------------
>
>                 Key: EMERGENCY-94
>                 URL: https://issues.oasis-open.org/browse/EMERGENCY-94
>             Project: OASIS Emergency Management TC
>          Issue Type: Bug
>          Components: TEP
>         Environment: Normative
>            Reporter: Patti Aymond
>            Assignee: Patti Aymond
>            Priority: Critical
>
> 1.4 Terminology reads in part: 
> ***** 
> The term “REQUIRED” means that empty elements or NULL values are NOT allowed. 
> ***** 
> The draft cites RFC 2119, which defines "REQUIRED" under: 
> ***** 
> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 
> ***** 
> That definition doesn't apply to empty elements or NULL values. 
> After citing RFC2119, the draft defines "REQUIRED" to disallow empty elements or NULL values. 
> Those two definitions are at odds with one another. The first is for conformance and the second is for markup. 
> TEPMessage reads in part: 
> Usage 
> ***** 
> REQUIRED; MUST be used once and only once 
> ***** 
> I don't see what REQUIRED is adding to the "MUST" ? 
> The vast majority of the REQUIRED instances read as messageID does in part: 
> ***** 
> Usage REQUIRED; MUST be used once and only once [1..1] 
> ***** 
> So if you are going to use markup constraints [1...1] why do you need the REQUIRED? 
> There are forty-three (43) cases and I think I have checked all of them. The secondary use of REQUIRED conflicts with RFC2119 and is redundant as far as I can see.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]