Issue 18435: QUDV Unit/QuantityKind name redundancy (sysml-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind: <!--[if !supportLists]-->a) <!--[endif]-->by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification) <!--[if !supportLists]-->b) <!--[endif]-->by the property Unit::name and QuantityKind::name This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind Resolution: Revised Text: Actions taken: February 10, 2013: reeived issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "sysml-rtf@omg.org" Subject: QUDV Unit/QuantityKind name redundancy Thread-Topic: QUDV Unit/QuantityKind name redundancy Thread-Index: AQHOB924z7mGzDSpTUaWVB6yoSWorg== Date: Sun, 10 Feb 2013 22:26:50 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Jurgen, Please file the following as an issue for the SysML RTF: Title: QUDV Unit/QuantityKind name redundancy Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Summary: SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind: a) by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification) b) by the property Unit::name and QuantityKind::name This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind. - Nicolas. From: "Rouquette, Nicolas F (313K)" To: "sysml-rtf@omg.org" Subject: Re: QUDV Unit/QuantityKind name redundancy Thread-Topic: QUDV Unit/QuantityKind name redundancy Thread-Index: AQHOB924z7mGzDSpTUaWVB6yoSWorphzraGA Date: Sun, 10 Feb 2013 22:33:48 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org I drafted a proposed resolution for this issue (see attached). This document is on the Annex D wiki page here: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:annex_d_non-normative_extensions The document is also on SVN along with a MagicDraw 17.0.2 model of OMG SysML 1.3 + the proposed fix: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/QUDV-Unit_QK_name_redundancy.doc http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 JPL/OMG-SysML1.3+QUDVnameDuplicationFix.mdzip - Nicolas. From: , JPL Date: Sunday, February 10, 2013 2:26 PM To: "issues@omg.org" Cc: "sysml-rtf@omg.org" Subject: QUDV Unit/QuantityKind name redundancy Jurgen, Please file the following as an issue for the SysML RTF: Title: QUDV Unit/QuantityKind name redundancy Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Summary: SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind: a) by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification) b) by the property Unit::name and QuantityKind::name This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind. - Nicolas. QUDV-Unit_QK_name_redundancy.doc Disposition: Resolved OMG Issue No: 18435 Title: QUDV Unit/QuantityKind name redundancy Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Summary: SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind: a) by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification) b) by the property Unit::name and QuantityKind::name This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind. Discussion: The duplication is indeed unnecessary. In fact, the none of the definitions of Units and QuantityKinds in the ISO-80000-1-QUDV library have slots for the Unit::name or QuantityKind::name properties. Remove Unit::name and QuantityKind::name. Resolution: In D.5.2, replace Figure D.8, currently: with the following: In D.5.2, replace Figure D.9, currently: with the following: In D.5.2, replace Figure D.10, currently: with the following: In D.5.2.10, QuantityKind, Properties, delete the following: . name: String. Name of the kind of quantity. In D.5.2.20, Unit, Properties, delete the following: . name: String. Name of the unit. Disposition: Resolved From: "Rouquette, Nicolas F (313K)" To: Burkhart Roger M , Conrad Bock CC: "sysml-rtf@omg.org" Subject: 18435 resolution, v2 Thread-Topic: 18435 resolution, v2 Thread-Index: AQHOC7rXP3CavLMvdkS8cyORV+ImHg== Date: Fri, 15 Feb 2013 20:27:13 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org It's on the wiki: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:annex_d_non-normative_extensions It's also in SVN: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18435_resolved_NFR_v2.doc With the updated SysML 1.3 + 18435 MD 17.0.2 model: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 JPL/OMG-SysML1.3+18435.mdzip - Nicolas. 18435_resolved_NFR_v2.doc From: Burkhart Roger M To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: Ac5LQRlmO63R5VevRK+8TD7XFIKmCg== Date: Tue, 7 May 2013 16:37:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [204.54.37.221] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-07_06:2013-05-07,2013-05-07,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-07_06:2013-05-07,2013-05-07,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: "Rouquette, Nicolas F (313K)" To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzCw== Date: Tue, 7 May 2013 20:08:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. If SysML 1.4 is based on UML 2.4.1, then you could make a case that this problem is isolated to the spec development. if SysML 1.4 is based on UML 2.5, then there's a real problem because the UML 2.5 and SysML 1.4 conventions are incompatible. UML 2.5 says the keyword for StandardProfile::Metaclass is "Metaclass", not "metaclass" From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: "Rouquette, Nicolas F (313K)" To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzC5j6JqeA Date: Tue, 7 May 2013 20:08:58 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0delmo X-Brightmail-Tracker: AAAAAA== Sorry, I typed send before I finished editing my message. From: , JPL Date: Tuesday, May 7, 2013 1:08 PM To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. - Nicolas. From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: Burkhart Roger M To: "Rouquette, Nicolas F (313K)" , "sysml-rtf@omg.org" Subject: RE: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzC5j6JqeAgAEVQ+A= Date: Wed, 8 May 2013 12:59:17 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [204.54.37.222] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-08_03:2013-05-08,2013-05-08,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-08_03:2013-05-08,2013-05-08,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Nicolas, My point below is that the block stereotypes do not need to be shown at all in diagrams D.8-D.10, and in fact should not be shown for compatibility with the existing diagrams in SysML 1.2 and 1.3. This is regardless of whether we base SysML 1.4 on UML 2.4 or UML 2.5. Whether or not you happen to have tool support for the valueType keyword (the only one which needs to appear), we can always fix that by final editing on the EPS graphics imported by the spec. That's exactly we've done with the last two SysML versions, so none of this is new. It would require a substantial change across the entire SysML spec to change the capitalization conventions we've followed since SysML 1.0 (when all graphics were produced by Visio, which is at least one tool that supports SysML conventions). Could you produce a version of the diagrams without the block keywords, thus matching the style in diagrams D.8-D.10 in SysML 1.3 as closely as possible, so we can produce a version of the resolution for balloting? (The tool you use does support suppressing the stereotype keyword altogether on the shape.) Then you could send either the model source file or exported EPS graphics which I can put into the resolution. If need be, we can leave any remaining cleanup for the production of the final spec, as we ended up doing in the past. --Roger From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 07, 2013 3:09 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Sorry, I typed send before I finished editing my message. From: , JPL Date: Tuesday, May 7, 2013 1:08 PM To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. - Nicolas. From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: "Rouquette, Nicolas F (313K)" To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzC5j6JqeAgAEVQ+CAABhjAA== Date: Wed, 8 May 2013 14:08:34 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0delmo X-Brightmail-Tracker: AAAAAA== Roger, I've used MagicDraw for SysML 1.4. Nerijus informed me about their DSL technique to build support for the SysML lowercase keyword notation for stereotype names; including UML's. I'll update the figures accordingly including your suggestions for which stereotype keywords to show or hide. Nicolas. From: Burkhart Roger M Date: Wednesday, May 8, 2013 5:59 AM To: JPL , "sysml-rtf@omg.org" Subject: RE: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Nicolas, My point below is that the block stereotypes do not need to be shown at all in diagrams D.8-D.10, and in fact should not be shown for compatibility with the existing diagrams in SysML 1.2 and 1.3. This is regardless of whether we base SysML 1.4 on UML 2.4 or UML 2.5. Whether or not you happen to have tool support for the valueType keyword (the only one which needs to appear), we can always fix that by final editing on the EPS graphics imported by the spec. That's exactly we've done with the last two SysML versions, so none of this is new. It would require a substantial change across the entire SysML spec to change the capitalization conventions we've followed since SysML 1.0 (when all graphics were produced by Visio, which is at least one tool that supports SysML conventions). Could you produce a version of the diagrams without the block keywords, thus matching the style in diagrams D.8-D.10 in SysML 1.3 as closely as possible, so we can produce a version of the resolution for balloting? (The tool you use does support suppressing the stereotype keyword altogether on the shape.) Then you could send either the model source file or exported EPS graphics which I can put into the resolution. If need be, we can leave any remaining cleanup for the production of the final spec, as we ended up doing in the past. --Roger From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 07, 2013 3:09 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Sorry, I typed send before I finished editing my message. From: , JPL Date: Tuesday, May 7, 2013 1:08 PM To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. - Nicolas. From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger image0012.png