Issue 16871: Annex F is in the wrong specification (sbvr-rtf) Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: Date/Time Annex F is titled: Annex F Simplified Syntax for Logical Formulations. First, the title is wrong. The Date/Time standard contains logical formulations in OCL and CLIF. This Annex is a syntax for SBVR 'logical formulations', and this language, like SBVR Structured English, is somehow related to the vocabulary of SBVR clause 9. It should be titled: Simplified Syntax for SBVR Logical Formulations. Secondly, as a consequence, this Annex is totally out of place in the Date/Time Vocabulary specification. If this is a useful notation for SBVR formulations, and is used in the SBVR community, then it should surely be an informative annex to the SBVR v1.1 specification, and simply be referenced in the Date/Time Annex (E) that uses it. If it is not used in the SBVR community, then it is certainly inappropriate for Date/Time to include it. Recommendation: Delete Annex F and refer to the OMG (SBVR) specification that actually includes it. Otherwise, use a standardized SBVR notation in Annex E. The Date/Time final submission should have identified Annex F as a proposed addition to the SBVR specification -- a new informative Annex, and we may assert that OMG adoption of the Date/Time submission constitutes adoption of Annex F as an addition to the SBVR specification. Resolution: This issue is transferred to the SBVR-RTF as a possible enhancement of the SBVR specification. If and when the SBVR-RTF decides how to handle this issue, the Date-Time Vocabulary should be updated to match. Revised Text: (none) Disposition: Transferred to SBVR RTF-2 Revised Text: Actions taken: December 1, 2011: received issue April 10, 2012: closed issue January 8, 2013: transferred to SBVR 2 RTF from DTV FTF Discussion: End of Annotations:===== te: Thu, 01 Dec 2011 16:43:54 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: issues@omg.org CC: "date-time-ftf@omg.org" , SBVR RTF Subject: Date/Time Vocabulary Issue: Annex F is in the wrong specification X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: pB1Li06i019535 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1323380640.35312@NdMS8hVw4sJQODNga8Plkg X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov OMG Issue Specification: Date/Time Vocabulary (DTV) Version: draft Beta-1 Title: Annex F is in the wrong specification Source: Ed Barkmeyer, NIST, edbark@nist.gov Summary: Date/Time Annex F is titled: Annex F Simplified Syntax for Logical Formulations. First, the title is wrong. The Date/Time standard contains logical formulations in OCL and CLIF. This Annex is a syntax for SBVR 'logical formulations', and this language, like SBVR Structured English, is somehow related to the vocabulary of SBVR clause 9. It should be titled: Simplified Syntax for SBVR Logical Formulations. Secondly, as a consequence, this Annex is totally out of place in the Date/Time Vocabulary specification. If this is a useful notation for SBVR formulations, and is used in the SBVR community, then it should surely be an informative annex to the SBVR v1.1 specification, and simply be referenced in the Date/Time Annex (E) that uses it. If it is not used in the SBVR community, then it is certainly inappropriate for Date/Time to include it. Recommendation: Delete Annex F and refer to the OMG (SBVR) specification that actually includes it. Otherwise, use a standardized SBVR notation in Annex E. The Date/Time final submission should have identified Annex F as a proposed addition to the SBVR specification -- a new informative Annex, and we may assert that OMG adoption of the Date/Time submission constitutes adoption of Annex F as an addition to the SBVR specification. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 Date: Fri, 27 Jan 2012 19:46:02 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: OMG Date/Time Team , SBVR RTF Subject: Re: Date/Time Issue 16871 - notation for SBVR logical formulations X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q0S0k76h009939 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1328316371.92107@Ewk9er61iKe01F7YC6EIWA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Date/Time issue 16871 says that Date/Time Annex F -- a notation for SBVR logical formulations -- should be in the SBVR specification and not a part of the Date/Time specification. NIST raised this issue. We believe that procedurally, this should have been reviewed by the SBVR RTF, and unfortunately was not. The proper disposition of Annex F of the Date/Time submission by the FTF should have been to submit it as an adopted informative annex to SBVR, and let the SBVR 1.2 RTF deal with it. Yes, it was inconvenient in Annex E of Date/Time to use the style of presentation of logical formulations that is used in the SBVR standard. But it is inconvenient to every user of SBVR to explain logical formulations as a long string of English sentences. The concern is not specific to Date/time. There is value to this Annex, but it generallizes to the whole SBVR implementor community. If it is deemed by that community to have value, it should be a part of SBVR. In any case, it is wholly out of place in Date/Time. It is outside the scope, and irrelevant to the purpose. And we do not believe it has had adequate review, simply because it was not submitted to review by the SBVR RTF. As evidence that it has had inadequate review, I offer the following technical comments on the Annex: 1. It does not specify a grammar for the notation/language. It is possible to glean many elements of the intended grammar from the table, but it is not clear that it is complete or unambiguous. It specifies a pattern recognition for SBVR constructs, without guaranteeing that the patterns are unique. 2. None of the lexical elements is even described. It does not define the character set. It does not define the lexical rules for representing an SBVR vocabulary term. Does it presume the inclusion of presentation markup in the lexical representation, like Annex C does? It refers to "quoted string" without specifying the "quote" character(s) or the character set they may enclose. It does not specify the lexical rules for forming a "variable". In short, there is no guidance for the structure of many of the elements in pointy brackets in the table. 3. It says that the scope of a grammatical construct is determined by "indenting", which means that some characters are used to "indent", but it doesn't specify what characters denote indentation. Those "indent" characters are markers for grammatical constructs, like the scope of quantifiers. They are critical to enabling the pattern recognition that is the basis for a grammar. It must specify the indent characters and how they relate to 'depth' -- the measurement of "further to the right". It doesn't talk about 'lines', which must have a meaning with respect to "indenting". In short, it does not appear that this Annex specifies a notation that is meant to be parsed, or even unambiguously interpreted by human readers. It is phrased as a guideline that specifies the image of a logical formulation on a printed page. Since the only standard representation of SBVR logical formulations is in XML, it seems that it would be advisable to have some such formal representation, particularly since the relationship between the grammatical elements of SBVR Structured English and the 'structures of meaning' in Clause 9 is not clearly defined in Annex C (or anywhere else). This is an opportunity. Since this Annex was formally adopted by the OMG, the RTF has the authority to "repair" it into an effective specification for a useful notation, as an Annex to SBVR. NIST recommends that the SBVR 1.2 RTF take that responsibility, and that the Annex be removed from the finalized Date/Time specification. If the SBVR RTF decides that adopting this Annex is not worthwhile, then the Annex should be scrapped. That was the point of the issue. The point of this email is to create a future agenda item for the SBVR RTF to discuss its disposition. Alternatively, we can all wait until the Date/Time FTF decides to ask formally, or decides not to. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 Date: Fri, 27 Jan 2012 19:46:02 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: OMG Date/Time Team , SBVR RTF Subject: Re: Date/Time Issue 16871 - notation for SBVR logical formulations X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q0S0k76h009939 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1328316371.92107@Ewk9er61iKe01F7YC6EIWA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Date/Time issue 16871 says that Date/Time Annex F -- a notation for SBVR logical formulations -- should be in the SBVR specification and not a part of the Date/Time specification. NIST raised this issue. We believe that procedurally, this should have been reviewed by the SBVR RTF, and unfortunately was not. The proper disposition of Annex F of the Date/Time submission by the FTF should have been to submit it as an adopted informative annex to SBVR, and let the SBVR 1.2 RTF deal with it. Yes, it was inconvenient in Annex E of Date/Time to use the style of presentation of logical formulations that is used in the SBVR standard. But it is inconvenient to every user of SBVR to explain logical formulations as a long string of English sentences. The concern is not specific to Date/time. There is value to this Annex, but it generallizes to the whole SBVR implementor community. If it is deemed by that community to have value, it should be a part of SBVR. In any case, it is wholly out of place in Date/Time. It is outside the scope, and irrelevant to the purpose. And we do not believe it has had adequate review, simply because it was not submitted to review by the SBVR RTF. As evidence that it has had inadequate review, I offer the following technical comments on the Annex: 1. It does not specify a grammar for the notation/language. It is possible to glean many elements of the intended grammar from the table, but it is not clear that it is complete or unambiguous. It specifies a pattern recognition for SBVR constructs, without guaranteeing that the patterns are unique. 2. None of the lexical elements is even described. It does not define the character set. It does not define the lexical rules for representing an SBVR vocabulary term. Does it presume the inclusion of presentation markup in the lexical representation, like Annex C does? It refers to "quoted string" without specifying the "quote" character(s) or the character set they may enclose. It does not specify the lexical rules for forming a "variable". In short, there is no guidance for the structure of many of the elements in pointy brackets in the table. 3. It says that the scope of a grammatical construct is determined by "indenting", which means that some characters are used to "indent", but it doesn't specify what characters denote indentation. Those "indent" characters are markers for grammatical constructs, like the scope of quantifiers. They are critical to enabling the pattern recognition that is the basis for a grammar. It must specify the indent characters and how they relate to 'depth' -- the measurement of "further to the right". It doesn't talk about 'lines', which must have a meaning with respect to "indenting". In short, it does not appear that this Annex specifies a notation that is meant to be parsed, or even unambiguously interpreted by human readers. It is phrased as a guideline that specifies the image of a logical formulation on a printed page. Since the only standard representation of SBVR logical formulations is in XML, it seems that it would be advisable to have some such formal representation, particularly since the relationship between the grammatical elements of SBVR Structured English and the 'structures of meaning' in Clause 9 is not clearly defined in Annex C (or anywhere else). This is an opportunity. Since this Annex was formally adopted by the OMG, the RTF has the authority to "repair" it into an effective specification for a useful notation, as an Annex to SBVR. NIST recommends that the SBVR 1.2 RTF take that responsibility, and that the Annex be removed from the finalized Date/Time specification. If the SBVR RTF decides that adopting this Annex is not worthwhile, then the Annex should be scrapped. That was the point of the issue. The point of this email is to create a future agenda item for the SBVR RTF to discuss its disposition. Alternatively, we can all wait until the Date/Time FTF decides to ask formally, or decides not to. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 To: sbvr-rtf@omg.org Subject: Issue 16871 - Annex F is in the Wrong Specification X-KeepSent: D5DC400F:3EA5E216-85257A6D:00681479; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Mark H Linehan Date: Sun, 2 Sep 2012 20:01:27 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3FP2IF1|July 25, 2012) at 09/02/2012 20:01:27 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12090300-9360-0000-0000-00000A1F01C0 The DTV FTF is transferring issue 16871 entitled "Annex F is in the Wrong Specification" to the SBVR-RTF. The issue complains that Don Baisley's abbreviated syntax for specifying SBVR logical formulations belongs in the SBVR specification, not in the Date-Time Vocabulary specification. If the SBVR-RTF agrees to add it to the SBVR specification, then it should be removed from the Date-Time Vocabulary document. -------------------------------- Mark H. Linehan STSM, IBM Research Date-Time Issue 16871 - Annex F is in the Wrong Specification.doc Disposition: Transferred OMG Issue No: 16871 Title: Annex F is in the wrong specification Source: Ed Barkmeyer, NIST, edbark@nist.gov Summary: Date/Time Annex F is titled: Annex F Simplified Syntax for Logical Formulations. First, the title is wrong. The Date/Time standard contains logical formulations in OCL and CLIF. This Annex is a syntax for SBVR 'logical formulations', and this language, like SBVR Structured English, is somehow related to the vocabulary of SBVR clause 9. It should be titled: Simplified Syntax for SBVR Logical Formulations. Secondly, as a consequence, this Annex is totally out of place in the Date/Time Vocabulary specification. If this is a useful notation for SBVR formulations, and is used in the SBVR community, then it should surely be an informative annex to the SBVR v1.1 specification, and simply be referenced in the Date/Time Annex (E) that uses it. If it is not used in the SBVR community, then it is certainly inappropriate for Date/Time to include it. Recommendation: Delete Annex F and refer to the OMG (SBVR) specification that actually includes it. Otherwise, use a standardized SBVR notation in Annex E. The Date/Time final submission should have identified Annex F as a proposed addition to the SBVR specification -- a new informative Annex, and we may assert that OMG adoption of the Date/Time submission constitutes adoption of Annex F as an addition to the SBVR specification. Resolution: This issue is transferred to the SBVR-RTF as a possible enhancement of the SBVR specification. If and when the SBVR-RTF decides how to handle this issue, the Date-Time Vocabulary should be updated to match. Revised Text: (none) Disposition: Transferred to SBVR RTF-2