Issue 16166: Distinguishing between Representation Expressions With and Without Embedded Markup (sbvr-rtf) Source: Business Semantics Ltd. (Mr. Donald R. Chapin, Donald.Chapin(at)BusinessSemantics.com) Nature: Uncategorized Issue Severity: Summary: SBVR is not clear about how markup should or should not be embedded within Representation Expressions. The specification needs to be clear about exactly what is included in basic Representation Expressions, especially Fact Type Forms, which contain no embedded markup. It also needs to be clear about the kinds of markup that can be embedded in Representation Expressions and how to communicate which markup specification is being used. Resolution: Revised Text: Actions taken: May 6, 2011: received issue Discussion: End of Annotations:===== m: "Donald Chapin" To: "'Juergen Boldt'" Subject: RE: FW: Draft resolution for SBVR Issue 13804 Date: Fri, 6 May 2011 13:16:59 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwL28162nJcPP9dTHS1XCkw7wuAZgAC6RBQ X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4DC3E6D0.0050, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.6.115717:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_BOLD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, __RATWARE_SIGNATURE_3_N1, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4DC3E75E.0204,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Thanks, Juergen. Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 06 May 2011 11:53 To: Donald Chapin Subject: Re: FW: Draft resolution for SBVR Issue 13804 ahhh ok....will do today, Donald -Juergen At 05:35 AM 5/6/2011, you wrote: Hi Juergen, I need a number for this Issue. Can you process my request below for me? If there is some question about this, please let me know. Many Thanks, Donald -----Original Message----- From: Donald Chapin [ mailto:donald.chapin@btconnect.com] Sent: 29 April 2011 09:29 To: 'Juergen Boldt'; 'issues@omg.org' Subject: FW: Draft resolution for SBVR Issue 13804 Importance: High Hi Juergen, When I checked just now I did not see this as a new Issue on the OMG's SBVR RTF Issue list. Could you give this an Issue number as per the Issue title and description in my March 30th email below? Many Thanks, Donald -----Original Message----- From: Donald Chapin [ mailto:donald.chapin@btconnect.com] Sent: 15 April 2011 11:35 To: 'Juergen Boldt' Subject: FW: Draft resolution for SBVR Issue 13804 Hi Juergen, I (thought I) sent this email to you, but have just discovered that I omitted your email address! Could you assign what is in Ed's document as new Issue number with the Title and Issue Description as shown in my email below? Many Thanks, Donald -----Original Message----- From: Donald Chapin [ mailto:donald.chapin@btconnect.com] Sent: 30 March 2011 09:35 To: 'sbvr-rtf@omg.org' Subject: FW: Draft resolution for SBVR Issue 13804 Juergen, Since SBVR Issue 13804 is already resolved, can you submit the attached as a new SBVR Issue: Issue Title: Distinguishing between Representation Expressions With and Without Embedded Markup Issue Description: SBVR is not clear about how markup should or should not be embedded within Representation Expressions. The specification needs to be clear about exactly what is included in basic Representation Expressions, especially Fact Type Forms, which contain no embedded markup. It also needs to be clear about the kinds of markup that can be embedded in Representation Expressions and how to communicate which markup specification is being used. Thanks, Donald -----Original Message----- From: Ed Barkmeyer [ mailto:edbark@nist.gov] Sent: 17 March 2011 22:28 To: SBVR RTF Subject: Draft resolution for SBVR Issue 13804 Issue 13804 was last discussed a year ago. I composed the attached draft from my notes of that discussion. It doubtless still needs work, but perhaps we can clean this one up. The crux of this is not the issue as written; that was mostly resolved in 13802 in the interim document. The problem we discovered during the discussion is that we assume without ever saying it that the exchange form of fact type forms is plain text (which is not, of course, what one sees in the SBVR specification). -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 Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org From: "Donald Chapin" To: Subject: RE: issue 16166 -- SBVR RTF issue Date: Fri, 6 May 2011 15:29:15 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwL84rELAAx3b7cQdyr7zsYGzsysAABdjsg X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4DC405D0.002D, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.5.6.135423:17:9.975, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, LINK_TO_IMAGE, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_BOLD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __IMGSPAM_BODY, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, __RATWARE_SIGNATURE_3_N1, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK, IMGSPAM_BODY X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4DC40649.00D7,ss=1,vtr=str,vl=0,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Update of Proposed Resolution of Issue 16166 from notes of March 24th Face to Face SBVR RTF. -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 06 May 2011 14:41 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16166 -- SBVR RTF issue -----Original Message----- From: Donald Chapin [ mailto:donald.chapin@btconnect.com] Sent: 30 March 2011 09:35 To: 'sbvr-rtf@omg.org' Subject: FW: Draft resolution for SBVR Issue 13804 Juergen, Since SBVR Issue 13804 is already resolved, can you submit the attached as a new SBVR Issue: Issue Title: Distinguishing between Representation Expressions With and Without Embedded Markup Issue Description: SBVR is not clear about how markup should or should not be embedded within Representation Expressions. The specification needs to be clear about exactly what is included in basic Representation Expressions, especially Fact Type Forms, which contain no embedded markup. It also needs to be clear about the kinds of markup that can be embedded in Representation Expressions and how to communicate which markup specification is being used. Thanks, Donald -----Original Message----- From: Ed Barkmeyer [ mailto:edbark@nist.gov] Sent: 17 March 2011 22:28 To: SBVR RTF Subject: Draft resolution for SBVR Issue 13804 Issue 13804 was last discussed a year ago. I composed the attached draft from my notes of that discussion. It doubtless still needs work, but perhaps we can clean this one up. The crux of this is not the issue as written; that was mostly resolved in 13802 in the interim document. The problem we discovered during the discussion is that we assume without ever saying it that the exchange form of fact type forms is plain text (which is not, of course, what one sees in the SBVR specification). -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 Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org SBVR Issue - Issue 16166 - Distinguishing between Rewpresentation Expressions With and Without Embedded Markup.doc Disposition: Resolved OMG Issue No: nnn Title: Distinguishing between Representation Expressions With and Without Embedded Markup Source: Ed Barkmeyer, NIST (edbark@nist.gov) Summary: SBVR is not clear about how markup should or should not be embedded within Representation Expressions. The specification needs to be clear about exactly what is included in basic Representation Expressions, especially Fact Type Forms, which contain no embedded markup. It also needs to be clear about the kinds of markup that can be embedded in Representation Expressions and how to communicate which markup specification is being used. Resolution: It is inappropriate for SBVR to describe the syntax of expressions at all, and the idea of a sub-expression model is inappropriate for that reason as well. SBVR needs only to model the abstract syntax . the interpretation of the fact type form as comprising a designation for the .verb concept. itself and a set of designations for the fact type roles . the placeholders. The existing text supports this model. Because SBVR makes the fact type form the principal representation of a fact type in a conceptual schema, however, it is necessary for SBVR to standardize at least one fact type form syntax, so that SBVR tooling can successfully exchange conceptual schemas. The intention of clause 8.3.4 is to standardize one expression of the fact type form as a character string comprising a sequence of signifiers (placeholders and verb signifier) without additional markup. The function of 'starting character position' is to locate the substring that is the placeholder expression (verbatim) within that string. The text will be clarified on this point. In examining this issue, however, it was noted that .starting character position. is not defined in this section. The entry will be moved. The fact type 'placeholder uses designation' refers to a convention used in SBVR Structured English syntax, and thus has no reason to be standardized. It will be deleted, to avoid any confusion for users of the specification. (They are free to define whatever conventions they will.) Having clarified that the standard exchange form for fact type forms is "plain text", the remaining concern of the RTF was to enable other fact type form representations of the same fact type that use markup, as the SBVR specification itself does, while making it clear that these are not intended to be 'synonymous forms'. The intent is only to distinguish the 'plain text form' of an expression from a marked up form that uses XML or HTML markup syntax. This is addressed by adding a relationship among expressions. Revised Text: 1a. In clause 8.2 DELETE the entire entry for starting character position, including the Definition and the Concept type. 1b. In clause 8.3.4, immediately before the entry for placeholder is at starting character position, INSERT: starting character position Definition: positive integer that designates the ordinal position of the first character of a text expression within an encompassing text expression Concept Type: role 2. In clause 8.2, immediately after the entry for text, INSERT a new entry: text1 stylizes is marked-up version of text2 Definition: text1 is a marked-up version of text2, using some conventions for display and other text characteristics, such that text1 less all mark-up is identical to text2. Note: Text2 is the .plain text. that is required in interchange documents. Text1 is optional. Note: This fact type allows an SBVR exchange document to contain shared signifiers in plain text form and relate them to some preferred display form, or some form that provides additional markups for other dictionary and vocabulary usages. For example, text1 may use XML or HTML markups based on a specified stylesheet. Similarly, part of a signifier may be marked up to refer to another entry, as this specification uses signifiers for noun concepts within placeholder expressions. 3 In clause 8.3.4, in the entry for fact type form, immediately before the first Necessity paragraph, INSERT: Note: For exchange purposes, it is a requirement that the expression representing the fact type form be a plain text character string in which the signifiers for the verb and the roles appear verbatim. This permits conforming tools to correctly manage the vocabularies and conceptual schemas in which the fact type forms are the primary representation of the fact type. It also permits different tools to use different display conventions for the elements of a fact type form, such as those used in this specification, without having such conventions interfere with correct interpretation of the intended signifiers by other tools. Marked-up expressions, for tools that agree on markup conventions, can be linked to the plain text expression using text1 stylizes text2. 4. In clause 8.3.4, in the entry for placeholder is at starting character position, immediately after the Synonymous Form paragraph, INSERT: Note: The placeholder text expression shall appear character-for-character in the fact type form, beginning with the starting character position. 5. In clause 8.3.4, DELETE the entire entry for placeholder uses designation, including the Definition, the Note and all 3 Examples. Disposition: Resolved