Issue 13939: Parsing Text in Requirements (sysml-rtf) Source: (Mr. Sanford A. Friedenthal, ) Nature: Enhancement Severity: Significant Summary: Parsing Text in Requirements: There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements or perhaps to a URI. This will enable one to associated additional meaning to selected portions of the text string, such as a particular value, property name, function, or some other feature. A parsed text string which can refer to other elements could be generalized to support other uses within SysML where text is used. In this sense, the proposal could treat this in another chapter such as model elements to make it more generally applicable. One possible approach is to consider a net type called "ParsedText" that has some structure to it, so that the text can be parsed and a reference can be made from the parsed text. The Requirements text property would then be typed by ParsedText instead of String as it currently is. Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: May 27, 2009: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: Extensive discussion on this issue occurred during the 1.2 RTF, but not during the 1.3 RTF. The complete text of a proposed resolution from the 1.2 RTF discussions was included for future reference in a deferred resolution of this issue in the 1.2 RTF report. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 27 May 2009 23:06:20 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 16 FormalNumber: formal/2008-11-02 Version: 1.1 RevisionDate: 11/XX/2008 Page: 141 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) Description Parsing Text in Requirements: There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements or perhaps to a URI. This will enable one to associated additional meaning to selected portions of the text string, such as a particular value, property name, function, or some other feature. A parsed text string which can refer to other elements could be generalized to support other uses within SysML where text is used. In this sense, the proposal could treat this in another chapter such as model elements to make it more generally applicable. One possible approach is to consider a net type called "ParsedText" that has some structure to it, so that the text can be parsed and a reference can be made from the parsed text. The Requirements text property would then be typed by ParsedText instead of String as it currently is. Date: Tue, 02 Jun 2009 04:50:54 -0400 From: "Chonoles, Michael J" Subject: Issue 13939 -- SysML RTF issue To: "Friedenthal, Sanford" , issues@omg.org Cc: Burkhart Roger M , Tim Weilkiens , Fredrick A Steiner Thread-Topic: Issue 13939 -- SysML RTF issue Thread-Index: AcnfQahIth8FipqgSwOeCWSp0l1BpQAeCkvQAOkUH0A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 02 Jun 2009 08:50:55.0723 (UTC) FILETIME=[3DEED3B0:01C9E35F] Sandy, your proposed solution sounds reasonable, but where would you put the current values that the requirements text needs to point to? Generally these are constants, though they get changed if the requirement changes and the constants should support TBD/TBR/TBS/TBA. I have no problem if there is a convenient location for these values. I thought that placing them in another compartment of the requirement might be useful. I.m willing to find another place, especially since, placing them elsewhere would allow us to separate .classified. values from the requirement, supporting good security compartmentation. Michael Chonoles Date: Sat, 18 Jul 2009 14:35:53 -0400 From: "Chonoles, Michael J" Subject: RE: partial draft of Ballot 3 available for discussion To: "Friedenthal, Sanford" Cc: sysml-rtf@omg.org Thread-Topic: partial draft of Ballot 3 available for discussion Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQDOZhZAAAA4zHAACNiGoA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Jul 2009 18:40:59.0040 (UTC) FILETIME=[4AF4CA00:01CA07D7] Sandy "Relative to 'Issue 13939: Parsing Text in Requirements', perhaps the stereotype should extend the metaclass 'PrimitiveType' instead of 'String'. Refer to Fig 7.13 of the superspec. Michael, can you make this change" Yes, but I'm not sure this is an improvement, why? Some of the vendors need to make no change, and just treat this as a string. Others, could just change how they do string (as there are no rules forbidding them from doing with String what they should do with the new type). By making the stereotype off of a string, I think we give them more freedom, and less duplicate code. Michael -----Original Message----- From: Friedenthal, Sanford Sent: Saturday, July 18, 2009 10:29 AM To: Bock, Conrad; Chonoles, Michael J; Eldad Palachi; Tim Weilkiens; BERNARD, Yves Cc: 'sysml-rtf@omg.org' Subject: RE: partial draft of Ballot 3 available for discussion Roger I am hoping Yves/Tim, Michael and Eldad can make some adjustments to our proposals prior to issuing the ballot, including some of the issues Conrad raises below against flow port decomp, the partition construct, and parsed text, and and some of the comments I have provided flow port decomp and the partition concept. Yves/Tim, Michael, and Eldad, can you please respond to these concerns as noted below and the comments I provided separately. We need to get this resolved right away in order to get on the ballot. THANKS. Conrad The comments you refer to on 'Issue 13178: Port Decompostion and Flow Specification' seemed to apply to the general concept of flow ports and flow specifications rather than the specifics of this proposal. For example, the following statement is directed more generally and has little to do with our specific proposal for allowing a flow specification to be decomposed. "Multiple types of things flowing can be supported with atomic flow ports by defining a supertype of the multiple kinds of this flow, and using that single type for the atomic flow port. The current flow spec model doesn't scale, and in the long run will only be understandable by SysML "hackers", rather than actual systems engineers. Non-atomic flow ports are misleading even in the simple cases, such as the position and speed example, where the non-atomic port can be easily misread as saying speed and position must always flow together. " I do not agree that we should connect flow properties. This has been a source of confusion. In particular, there is confusion between the concept of the port as a connection point, and the flow property which represents the item that is relayed by the port. I have recommended that we connect ports and not flow properties. I would like to discuss this with you if you have time. Eldad, can you review the proposal and see if any adjustments can be made to address Conrads concerns. I would like to discuss this issue about connecting flow properties with whoever is interested, in addition to Conrad. Relative to 'Issue 13928: partition construct' the inconsistencies should be cleaned up. Yves or Tim, can respond to these issues along with the additional comments that I submitted (which have not been circulated to the RTF as a whole). Relative to 'Issue 13939: Parsing Text in Requirements', perhaps the stereotype should extend the metaclass 'PrimitiveType' instead of 'String'. Refer to Fig 7.13 of the superspec. Michael, can you make this change. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Saturday, July 18, 2009 10:04 AM To: 'sysml-rtf@omg.org' Subject: RE: partial draft of Ballot 3 available for discussion Roger, et al, Here are my comments on draft ballot 3 as it's currently posted (except for 13928). Sorry I won't be able to reply to comments very quickly, probably not until the weekend. My sense is the issues addressed here are a bit too much for a last ballot. Conrad - Issue 13178: Port Decomposition of a Flow Specification This resolution is burdensome to use because of the alternatings flow specs and nested ports that potentially have flow specs. It shows that supporting for multiple types of things flowing (non-atomic flow ports) is not worth the complication, especially when integrated with other functionality as this issue is attempting. Multiple types of things flowing can be supported with atomic flow ports by defining a supertype of the multiple kinds of this flow, and using that single type for the atomic flow port. The current flow spec model doesn't scale, and in the long run will only be understandable by SysML "hackers", rather than actual systems engineers. Non-atomic flow ports are misleading even in the simple cases, such as the position and speed example, where the non-atomic port can be easily misread as saying speed and position must always flow together. It is simpler to make a superclass of the Position and Speed (VelocityAspect) as the type of an atomic port. It is isn't even clear it is good system design to send two different kinds of information into the same port, rather than use separate ones. My suggestion would be to simplify the flow spec model before resolving this issue. In the resolution text, point 2, the restriction that flow properties cannot be linked by connectors should be removed. Modelers might want to do this to establish relationships between the things flowing. One example is mentioned in point 4 of the resolution text. - Issue 13928: partition construct I'm assuming the resolution in the draft ballot posted in the wiki is not the currently ballot (which seemed very inconsistent, eg, basing a stereotype on package when the resolution text said it shouldn't). These comments on on the one sent by Yves on Friday, July 17th. Do not use the term "group", at least not without an adjective (as in ActivityGroup). The figures are using different terminology than the text, eg "partition" instead of "attribute". The revised text changes the base class of View from Package to Constraint, is that intentional? If the base class is Constraint, then no additional stereotype is needed. Constraints in UML can already apply to multiple elements of any kind, and has a notation. If a new presentation options is desired, it can be defined directly on UML Constraint, without a stereotype. - Issue 13939: Parsing Text in Requirements This resolution shouldn't depend on a particular language, like HTML. It should take the approach of the rest of UML/SysML is used a multi-valued language tag to indicate the languages used in the markup. My suggestion is for a stereotype to introduce a language attribute. Modelers can specify HTML or other languages. BTW, are you sure String is a metaclass in UML? It appears in the primitive types section with the "primitive" keyword. I don't know whether it can be extended with a stereotype or not. LMCO Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally Date: Tue, 21 Jul 2009 15:20:26 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: parsed text comments and Ballot 3/Issue 13939 generally Thread-Index: AcoJGRvrYdoo01hcSaSrQ0mrM5oF9gBL5QQw From: "Pete Rivett" To: , "Chonoles, Michael J" Cc: "Bock, Conrad" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n6LMGa4q025825 I agree - OpaqueExpression already caters for Language and Body (in fact multiple of each). There should be a documented value for Language for html, that tools can reliably use for comparison. Rather than any old html, XHTML should seriously be considered to allow for easier inclusion in XML interchange. In contrast, trying to stereotype an 'instance' of String (or a subtype) would be very problematic for most tools (in fact it would have to be LiteralString to be at all practical - even then I suggest people actually try it in their tool of choice). The above is mostly moot though, since I think this issue should be 'closed no change' for reasons I shall explain... My interest being piqued, I had a more detailed look at the proposed resolution for 13939. I have serious concerns with it notwithstanding the above: - one of the main purposes seems to be to link to other elements - yet the construction of URIs for this is left undefined (aside: the MOF Facility spec does have a scheme for XMI - which will be included in the next version of XMI). The example uses a href of './system' which makes all sorts of assumptions. It is also envisaged that the URL can include references to properties of specific elements - again with no syntax. Without this, what chance any sort of interoperability? - another purpose is to link to diagrams, again with no indication as to how a diagram (in the model) is to be represented as a URL - for the links there is no referential integrity nor impact analysis (any sort of reverse link) - in essence this seems to be trying to build a model (linking to elements) without doing any modeling - either at the tool or the interchange level - it seems the underlying need is to intersperse model references with free/markup text. In which case this could be properly modeled/structured e.g. as a sequence of text fragments and model references (akin to a dependency). It would be easy to render this as HTML should a browser client be needed. But most UML/SysML tools are not browser clients anyway. Furthermore, a generic browser will not be able to make sense of URLs that reference internal model elements, nor will most tools be able to act as a server to make such content available. Unless I guess an embedded micro-language is used (which is not in the example). - It still begs the question as to how to reference diagrams in the model - defining properties to be of type MarkupString (as in revised Fig 7.2) will not readily work since it will just give the Stereotype instance not the string itself (and with no navigable property from the stereotype instance to the string value): it seems they should remain as String with the added constraint that the stereotype MarkupString must be applied to each instance - the specification that 'reasonable formatting markup should be followed' is unworthy. - unclear whether HTML support is required - could a wiki syntax variant be used instead? - finally, this proposed resolution, and the related changes needed to address the concerns above, seems to add significant new capability that goes beyond what an RTF should be doing IMHO. Regards Pete -----Original Message----- From: David Price [mailto:david.price@eurostep.com] Sent: 20 July 2009 02:03 To: Chonoles, Michael J Cc: Bock, Conrad; sysml-rtf@omg.org Subject: RE: parsed text comments Sounds to me like what's being suggested is that these two uses of String in the metamodel should actually be uses of OpaqueExpression. If that was the result, one could use it to specify property-based requirements too. Cheers, David On Sun, 2009-07-19 at 19:40 -0400, Chonoles, Michael J wrote: > Conrad, you're confusing what tools are doing with what they are being > required to do. We're requiring them to pass the entire string through > and to observe what markup they can, and to support references to > external and internal locations. Not all tools do this at this moment. > They are welcome to do it for all strings, but we're requiring this to > be done for requirements text and for viewpoint text (and modeler uses > of the stereotype string) > > My original approach was a type based on string, but people preferred > the stereotype. Go figure! > > Michael > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: Sunday, July 19, 2009 4:45 PM > To: sysml-rtf@omg.org > Subject: RE: parsed text comments > > Michael, > > > Sandy. the way I had left it, it would default to html, but accept > > any other form of markup language if the text of the field started > > with the correct header for that markup language. > > In that case, no stereotype is needed. Tools just look at any string to > check for the header. No need to distinguish the markedup ones from the > others. > > I have a general concern that introducing a stereotype for this forces > changes in all (meta) models that want to use marked up strings. They > already can use them, and tools can already recognize them. > > Conrad -- UK +44 20 8747 3900 Mobile +44 7788 561308 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ. Date: Tue, 21 Jul 2009 19:45:16 -0400 From: "Chonoles, Michael J" Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally To: Pete Rivett , david.price@eurostep.com Cc: "Bock, Conrad" , sysml-rtf@omg.org Thread-Topic: parsed text comments and Ballot 3/Issue 13939 generally Thread-Index: AcoJGRvrYdoo01hcSaSrQ0mrM5oF9gBL5QQwAAUXbjA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Jul 2009 23:52:23.0995 (UTC) FILETIME=[4B4BE8B0:01CA0A5E] We're really just trying to move closer to standardization on a capability that several of the tools do today. While it doesn't fix all the details, it reduces some of the wiggle room Michael -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, July 21, 2009 6:20 PM To: david.price@eurostep.com; Chonoles, Michael J Cc: Bock, Conrad; sysml-rtf@omg.org Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally I agree - OpaqueExpression already caters for Language and Body (in fact multiple of each). There should be a documented value for Language for html, that tools can reliably use for comparison. Rather than any old html, XHTML should seriously be considered to allow for easier inclusion in XML interchange. In contrast, trying to stereotype an 'instance' of String (or a subtype) would be very problematic for most tools (in fact it would have to be LiteralString to be at all practical - even then I suggest people actually try it in their tool of choice). The above is mostly moot though, since I think this issue should be 'closed no change' for reasons I shall explain... My interest being piqued, I had a more detailed look at the proposed resolution for 13939. I have serious concerns with it notwithstanding the above: - one of the main purposes seems to be to link to other elements - yet the construction of URIs for this is left undefined (aside: the MOF Facility spec does have a scheme for XMI - which will be included in the next version of XMI). The example uses a href of './system' which makes all sorts of assumptions. It is also envisaged that the URL can include references to properties of specific elements - again with no syntax. Without this, what chance any sort of interoperability? - another purpose is to link to diagrams, again with no indication as to how a diagram (in the model) is to be represented as a URL - for the links there is no referential integrity nor impact analysis (any sort of reverse link) - in essence this seems to be trying to build a model (linking to elements) without doing any modeling - either at the tool or the interchange level - it seems the underlying need is to intersperse model references with free/markup text. In which case this could be properly modeled/structured e.g. as a sequence of text fragments and model references (akin to a dependency). It would be easy to render this as HTML should a browser client be needed. But most UML/SysML tools are not browser clients anyway. Furthermore, a generic browser will not be able to make sense of URLs that reference internal model elements, nor will most tools be able to act as a server to make such content available. Unless I guess an embedded micro-language is used (which is not in the example). - It still begs the question as to how to reference diagrams in the model - defining properties to be of type MarkupString (as in revised Fig 7.2) will not readily work since it will just give the Stereotype instance not the string itself (and with no navigable property from the stereotype instance to the string value): it seems they should remain as String with the added constraint that the stereotype MarkupString must be applied to each instance - the specification that 'reasonable formatting markup should be followed' is unworthy. - unclear whether HTML support is required - could a wiki syntax variant be used instead? - finally, this proposed resolution, and the related changes needed to address the concerns above, seems to add significant new capability that goes beyond what an RTF should be doing IMHO. Regards Pete -----Original Message----- From: David Price [mailto:david.price@eurostep.com] Sent: 20 July 2009 02:03 To: Chonoles, Michael J Cc: Bock, Conrad; sysml-rtf@omg.org Subject: RE: parsed text comments Sounds to me like what's being suggested is that these two uses of String in the metamodel should actually be uses of OpaqueExpression. If that was the result, one could use it to specify property-based requirements too. Cheers, David On Sun, 2009-07-19 at 19:40 -0400, Chonoles, Michael J wrote: > Conrad, you're confusing what tools are doing with what they are being > required to do. We're requiring them to pass the entire string through > and to observe what markup they can, and to support references to > external and internal locations. Not all tools do this at this moment. > They are welcome to do it for all strings, but we're requiring this to > be done for requirements text and for viewpoint text (and modeler uses > of the stereotype string) > > My original approach was a type based on string, but people preferred > the stereotype. Go figure! > > Michael > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: Sunday, July 19, 2009 4:45 PM > To: sysml-rtf@omg.org > Subject: RE: parsed text comments > > Michael, > > > Sandy. the way I had left it, it would default to html, but accept > > any other form of markup language if the text of the field started > > with the correct header for that markup language. > > In that case, no stereotype is needed. Tools just look at any string to > check for the header. No need to distinguish the markedup ones from the > others. > > I have a general concern that introducing a stereotype for this forces > changes in all (meta) models that want to use marked up strings. They > already can use them, and tools can already recognize them. > > Conrad -- UK +44 20 8747 3900 Mobile +44 7788 561308 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ. X-WSS-ID: 0KN5QED-08-ROC-02 X-M-MSG: From: Burkhart Roger M To: "Chonoles, Michael J" , Pete Rivett , "david.price@eurostep.com" CC: "Bock, Conrad" , "sysml-rtf@omg.org" Date: Tue, 21 Jul 2009 19:23:02 -0500 Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally Thread-Topic: parsed text comments and Ballot 3/Issue 13939 generally Thread-Index: AcoJGRvrYdoo01hcSaSrQ0mrM5oF9gBL5QQwAAUXbjAAAUWGEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n6M0JRuW020963 Does it really go far enough to give any capability that tools aren't already free to implement, as you indicate several tools already do? Since it leaves any implementation as optional by any tool, does it leave things in essentially the same state we already have? --Roger -----Original Message----- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Tuesday, July 21, 2009 6:45 PM To: Pete Rivett; david.price@eurostep.com Cc: Bock, Conrad; sysml-rtf@omg.org Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally We're really just trying to move closer to standardization on a capability that several of the tools do today. While it doesn't fix all the details, it reduces some of the wiggle room Michael -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, July 21, 2009 6:20 PM To: david.price@eurostep.com; Chonoles, Michael J Cc: Bock, Conrad; sysml-rtf@omg.org Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally I agree - OpaqueExpression already caters for Language and Body (in fact multiple of each). There should be a documented value for Language for html, that tools can reliably use for comparison. Rather than any old html, XHTML should seriously be considered to allow for easier inclusion in XML interchange. In contrast, trying to stereotype an 'instance' of String (or a subtype) would be very problematic for most tools (in fact it would have to be LiteralString to be at all practical - even then I suggest people actually try it in their tool of choice). The above is mostly moot though, since I think this issue should be 'closed no change' for reasons I shall explain... My interest being piqued, I had a more detailed look at the proposed resolution for 13939. I have serious concerns with it notwithstanding the above: - one of the main purposes seems to be to link to other elements - yet the construction of URIs for this is left undefined (aside: the MOF Facility spec does have a scheme for XMI - which will be included in the next version of XMI). The example uses a href of './system' which makes all sorts of assumptions. It is also envisaged that the URL can include references to properties of specific elements - again with no syntax. Without this, what chance any sort of interoperability? - another purpose is to link to diagrams, again with no indication as to how a diagram (in the model) is to be represented as a URL - for the links there is no referential integrity nor impact analysis (any sort of reverse link) - in essence this seems to be trying to build a model (linking to elements) without doing any modeling - either at the tool or the interchange level - it seems the underlying need is to intersperse model references with free/markup text. In which case this could be properly modeled/structured e.g. as a sequence of text fragments and model references (akin to a dependency). It would be easy to render this as HTML should a browser client be needed. But most UML/SysML tools are not browser clients anyway. Furthermore, a generic browser will not be able to make sense of URLs that reference internal model elements, nor will most tools be able to act as a server to make such content available. Unless I guess an embedded micro-language is used (which is not in the example). - It still begs the question as to how to reference diagrams in the model - defining properties to be of type MarkupString (as in revised Fig 7.2) will not readily work since it will just give the Stereotype instance not the string itself (and with no navigable property from the stereotype instance to the string value): it seems they should remain as String with the added constraint that the stereotype MarkupString must be applied to each instance - the specification that 'reasonable formatting markup should be followed' is unworthy. - unclear whether HTML support is required - could a wiki syntax variant be used instead? - finally, this proposed resolution, and the related changes needed to address the concerns above, seems to add significant new capability that goes beyond what an RTF should be doing IMHO. Regards Pete -----Original Message----- From: David Price [mailto:david.price@eurostep.com] Sent: 20 July 2009 02:03 To: Chonoles, Michael J Cc: Bock, Conrad; sysml-rtf@omg.org Subject: RE: parsed text comments Sounds to me like what's being suggested is that these two uses of String in the metamodel should actually be uses of OpaqueExpression. If that was the result, one could use it to specify property-based requirements too. Cheers, David On Sun, 2009-07-19 at 19:40 -0400, Chonoles, Michael J wrote: > Conrad, you're confusing what tools are doing with what they are being > required to do. We're requiring them to pass the entire string through > and to observe what markup they can, and to support references to > external and internal locations. Not all tools do this at this moment. > They are welcome to do it for all strings, but we're requiring this to > be done for requirements text and for viewpoint text (and modeler uses > of the stereotype string) > > My original approach was a type based on string, but people preferred > the stereotype. Go figure! > > Michael > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: Sunday, July 19, 2009 4:45 PM > To: sysml-rtf@omg.org > Subject: RE: parsed text comments > > Michael, > > > Sandy. the way I had left it, it would default to html, but accept > > any other form of markup language if the text of the field started > > with the correct header for that markup language. > > In that case, no stereotype is needed. Tools just look at any string to > check for the header. No need to distinguish the markedup ones from the > others. > > I have a general concern that introducing a stereotype for this forces > changes in all (meta) models that want to use marked up strings. They > already can use them, and tools can already recognize them. > > Conrad -- UK +44 20 8747 3900 Mobile +44 7788 561308 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ. X-Trace: 269237605/mk-outboundfilter-1.mail.uk.tiscali.com/F2S/$F2S-NILDRAM-ACCEPTED/f2s-nildram-customers/84.12.98.161/None/david.price@eurostep.com X-SBRS: None X-RemoteIP: 84.12.98.161 X-IP-MAIL-FROM: david.price@eurostep.com X-SMTP-AUTH: X-MUA: Evolution 2.26.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUBAD9PZkpUDGKh/2dsb2JhbAAIwSQJkCGCLx+BQAU X-IronPort-AV: E=Sophos;i="4.43,245,1246834800"; d="scan'208";a="269237605" X-IP-Direction: IN Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally From: David Price Reply-To: david.price@eurostep.com To: Burkhart Roger M Cc: "Chonoles, Michael J" , Pete Rivett , "Bock, Conrad" , "sysml-rtf@omg.org" Organization: Eurostep Date: Wed, 22 Jul 2009 07:29:51 +0100 X-Mailer: Evolution 2.26.1 Adding to Pete's point, users don't expect non-standard tool capabilities to interchange successfully so putting something in the spec changes user expectations which is quite the same state as today. Do the vendors that have a capability today support dereferencable links to model elements? If so, how, and is the form used something they can all agree to standardize? If they only support XHTML in the text, then an options is that the spec could specify XHTML and say nothing about dereferencable model element links. Cheers, David On Tue, 2009-07-21 at 19:23 -0500, Burkhart Roger M wrote: > Does it really go far enough to give any capability that > tools aren't already free to implement, as you indicate several > tools already do? Since it leaves any implementation as > optional by any tool, does it leave things in essentially the > same state we already have? > > --Roger > > -----Original Message----- > From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] > Sent: Tuesday, July 21, 2009 6:45 PM > To: Pete Rivett; david.price@eurostep.com > Cc: Bock, Conrad; sysml-rtf@omg.org > Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally > > We're really just trying to move closer to standardization on a > capability that several of the tools do today. While it doesn't fix all > the details, it reduces some of the wiggle room > Michael > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Tuesday, July 21, 2009 6:20 PM > To: david.price@eurostep.com; Chonoles, Michael J > Cc: Bock, Conrad; sysml-rtf@omg.org > Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally > > I agree - OpaqueExpression already caters for Language and Body (in fact > multiple of each). > There should be a documented value for Language for html, that tools can > reliably use for comparison. > Rather than any old html, XHTML should seriously be considered to allow > for easier inclusion in XML interchange. > > In contrast, trying to stereotype an 'instance' of String (or a subtype) > would be very problematic for most tools (in fact it would have to be > LiteralString to be at all practical - even then I suggest people > actually try it in their tool of choice). > > The above is mostly moot though, since I think this issue should be > 'closed no change' for reasons I shall explain... > > My interest being piqued, I had a more detailed look at the proposed > resolution for 13939. > I have serious concerns with it notwithstanding the above: > - one of the main purposes seems to be to link to other elements > - yet the construction of URIs for this is left undefined (aside: the > MOF Facility spec does have a scheme for XMI - which will be included in > the next version of XMI). The example uses a href of './system' which > makes all sorts of assumptions. It is also envisaged that the URL can > include references to properties of specific elements - again with no > syntax. Without this, what chance any sort of interoperability? > - another purpose is to link to diagrams, again with no indication > as to how a diagram (in the model) is to be represented as a URL > - for the links there is no referential integrity nor impact > analysis (any sort of reverse link) > - in essence this seems to be trying to build a model (linking > to elements) without doing any modeling - either at the tool or the > interchange level > - it seems the underlying need is to intersperse model > references with free/markup text. In which case this could be properly > modeled/structured e.g. as a sequence of text fragments and model > references (akin to a dependency). It would be easy to render this as > HTML should a browser client be needed. But most UML/SysML tools are not > browser clients anyway. Furthermore, a generic browser will not be able > to make sense of URLs that reference internal model elements, nor will > most tools be able to act as a server to make such content available. > Unless I guess an embedded micro-language is used (which is not in the > example). > - It still begs the question as to how to reference diagrams in > the model > - defining properties to be of type MarkupString (as in revised > Fig 7.2) will not readily work since it will just give the Stereotype > instance not the string itself (and with no navigable property from the > stereotype instance to the string value): it seems they should remain as > String with the added constraint that the stereotype MarkupString must > be applied to each instance > - the specification that 'reasonable formatting markup should be > followed' is unworthy. > - unclear whether HTML support is required - could a wiki syntax > variant be used instead? > - finally, this proposed resolution, and the related changes > needed to address the concerns above, seems to add significant new > capability that goes beyond what an RTF should be doing IMHO. > > Regards > Pete > > -----Original Message----- > From: David Price [mailto:david.price@eurostep.com] > Sent: 20 July 2009 02:03 > To: Chonoles, Michael J > Cc: Bock, Conrad; sysml-rtf@omg.org > Subject: RE: parsed text comments > > Sounds to me like what's being suggested is that these two uses of > String in the metamodel should actually be uses of OpaqueExpression. If > that was the result, one could use it to specify property-based > requirements too. > > Cheers, > David > > On Sun, 2009-07-19 at 19:40 -0400, Chonoles, Michael J wrote: > > Conrad, you're confusing what tools are doing with what they are being > > required to do. We're requiring them to pass the entire string > through > > and to observe what markup they can, and to support references to > > external and internal locations. Not all tools do this at this moment. > > They are welcome to do it for all strings, but we're requiring this to > > be done for requirements text and for viewpoint text (and modeler uses > > of the stereotype string) > > > > My original approach was a type based on string, but people preferred > > the stereotype. Go figure! > > > > Michael > > > > -----Original Message----- > > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > > Sent: Sunday, July 19, 2009 4:45 PM > > To: sysml-rtf@omg.org > > Subject: RE: parsed text comments > > > > Michael, > > > > > Sandy. the way I had left it, it would default to html, but accept > > > any other form of markup language if the text of the field started > > > with the correct header for that markup language. > > > > In that case, no stereotype is needed. Tools just look at any string > to > > check for the header. No need to distinguish the markedup ones from > the > > others. > > > > I have a general concern that introducing a stereotype for this forces > > changes in all (meta) models that want to use marked up strings. They > > already can use them, and tools can already recognize them. > > > > Conrad -- UK +44 20 8747 3900 Mobile +44 7788 561308 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ. Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally Date: Wed, 22 Jul 2009 14:03:15 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: parsed text comments and Ballot 3/Issue 13939 generally Thread-Index: AcoKlkaXfuJhvEMKS+i7TCO5QvGxBAALNZBQ From: "BERNARD, Yves" To: , "Burkhart Roger M" Cc: "Chonoles, Michael J" , "Pete Rivett" , "Bock, Conrad" , X-OriginalArrivalTime: 22 Jul 2009 12:03:16.0396 (UTC) FILETIME=[655D46C0:01CA0AC4] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n6MC0ECY017690 I globally agree Pete's concerns and especially the fear that "it seems to be trying to build a model (linking to elements) without doing any modeling". It's useful and safe to generate HTML documentation with hyperlinks from a model. I'm not sure it is so useful to have those kind of hyperlinks in string typed properties but i'm sure it's not safe! ;o) Navigation between diagram is a useful feature too, but it's only mater of tools implementation from my point of view. Yves -----Message d'origine----- De : David Price [mailto:david.price@eurostep.com] Envoyé : mercredi 22 juillet 2009 08:30 À : Burkhart Roger M Cc : Chonoles, Michael J; Pete Rivett; Bock, Conrad; sysml-rtf@omg.org Objet : RE: parsed text comments and Ballot 3/Issue 13939 generally Adding to Pete's point, users don't expect non-standard tool capabilities to interchange successfully so putting something in the spec changes user expectations which is quite the same state as today. Do the vendors that have a capability today support dereferencable links to model elements? If so, how, and is the form used something they can all agree to standardize? If they only support XHTML in the text, then an options is that the spec could specify XHTML and say nothing about dereferencable model element links. Cheers, David On Tue, 2009-07-21 at 19:23 -0500, Burkhart Roger M wrote: > Does it really go far enough to give any capability that > tools aren't already free to implement, as you indicate several > tools already do? Since it leaves any implementation as > optional by any tool, does it leave things in essentially the > same state we already have? > > --Roger > > -----Original Message----- > From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] > Sent: Tuesday, July 21, 2009 6:45 PM > To: Pete Rivett; david.price@eurostep.com > Cc: Bock, Conrad; sysml-rtf@omg.org > Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally > > We're really just trying to move closer to standardization on a > capability that several of the tools do today. While it doesn't fix all > the details, it reduces some of the wiggle room > Michael > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Tuesday, July 21, 2009 6:20 PM > To: david.price@eurostep.com; Chonoles, Michael J > Cc: Bock, Conrad; sysml-rtf@omg.org > Subject: RE: parsed text comments and Ballot 3/Issue 13939 generally > > I agree - OpaqueExpression already caters for Language and Body (in fact > multiple of each). > There should be a documented value for Language for html, that tools can > reliably use for comparison. > Rather than any old html, XHTML should seriously be considered to allow > for easier inclusion in XML interchange. > > In contrast, trying to stereotype an 'instance' of String (or a subtype) > would be very problematic for most tools (in fact it would have to be > LiteralString to be at all practical - even then I suggest people > actually try it in their tool of choice). > > The above is mostly moot though, since I think this issue should be > 'closed no change' for reasons I shall explain... > > My interest being piqued, I had a more detailed look at the proposed > resolution for 13939. > I have serious concerns with it notwithstanding the above: > - one of the main purposes seems to be to link to other elements > - yet the construction of URIs for this is left undefined (aside: the > MOF Facility spec does have a scheme for XMI - which will be included in > the next version of XMI). The example uses a href of './system' which > makes all sorts of assumptions. It is also envisaged that the URL can > include references to properties of specific elements - again with no > syntax. Without this, what chance any sort of interoperability? > - another purpose is to link to diagrams, again with no indication > as to how a diagram (in the model) is to be represented as a URL > - for the links there is no referential integrity nor impact > analysis (any sort of reverse link) > - in essence this seems to be trying to build a model (linking > to elements) without doing any modeling - either at the tool or the > interchange level > - it seems the underlying need is to intersperse model > references with free/markup text. In which case this could be properly > modeled/structured e.g. as a sequence of text fragments and model > references (akin to a dependency). It would be easy to render this as > HTML should a browser client be needed. But most UML/SysML tools are not > browser clients anyway. Furthermore, a generic browser will not be able > to make sense of URLs that reference internal model elements, nor will > most tools be able to act as a server to make such content available. > Unless I guess an embedded micro-language is used (which is not in the > example). > - It still begs the question as to how to reference diagrams in > the model > - defining properties to be of type MarkupString (as in revised > Fig 7.2) will not readily work since it will just give the Stereotype > instance not the string itself (and with no navigable property from the > stereotype instance to the string value): it seems they should remain as > String with the added constraint that the stereotype MarkupString must > be applied to each instance > - the specification that 'reasonable formatting markup should be > followed' is unworthy. > - unclear whether HTML support is required - could a wiki syntax > variant be used instead? > - finally, this proposed resolution, and the related changes > needed to address the concerns above, seems to add significant new > capability that goes beyond what an RTF should be doing IMHO. > > Regards > Pete > > -----Original Message----- > From: David Price [mailto:david.price@eurostep.com] > Sent: 20 July 2009 02:03 > To: Chonoles, Michael J > Cc: Bock, Conrad; sysml-rtf@omg.org > Subject: RE: parsed text comments > > Sounds to me like what's being suggested is that these two uses of > String in the metamodel should actually be uses of OpaqueExpression. If > that was the result, one could use it to specify property-based > requirements too. > > Cheers, > David > > On Sun, 2009-07-19 at 19:40 -0400, Chonoles, Michael J wrote: > > Conrad, you're confusing what tools are doing with what they are being > > required to do. We're requiring them to pass the entire string > through > > and to observe what markup they can, and to support references to > > external and internal locations. Not all tools do this at this moment. > > They are welcome to do it for all strings, but we're requiring this to > > be done for requirements text and for viewpoint text (and modeler uses > > of the stereotype string) > > > > My original approach was a type based on string, but people preferred > > the stereotype. Go figure! > > > > Michael > > > > -----Original Message----- > > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > > Sent: Sunday, July 19, 2009 4:45 PM > > To: sysml-rtf@omg.org > > Subject: RE: parsed text comments > > > > Michael, > > > > > Sandy. the way I had left it, it would default to html, but accept > > > any other form of markup language if the text of the field started > > > with the correct header for that markup language. > > > > In that case, no stereotype is needed. Tools just look at any string > to > > check for the header. No need to distinguish the markedup ones from > the > > others. > > > > I have a general concern that introducing a stereotype for this forces > > changes in all (meta) models that want to use marked up strings. They > > already can use them, and tools can already recognize them. > > > > Conrad -- UK +44 20 8747 3900 Mobile +44 7788 561308 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Date: Sat, 18 Jul 2009 14:45:06 -0400 From: "Friedenthal, Sanford" Subject: parsed text comments To: "Chonoles, Michael J" Cc: "sysml-rtf@omg.org" Thread-Topic: parsed text comments Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQDOZhZAAAA4zHAACNiGoAAAvynw Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Michael In follow-up discussions with Roger this morning, I think we can leave this as a stereotype of string (which is a PrimitiveType). However, Roger is going to generalize the resolution to be less restrictive on the type of markup language to address Conrad's other concerns. -----Original Message----- From: Chonoles, Michael J Sent: Saturday, July 18, 2009 2:36 PM To: Friedenthal, Sanford Cc: sysml-rtf@omg.org Subject: RE: partial draft of Ballot 3 available for discussion Sandy "Relative to 'Issue 13939: Parsing Text in Requirements', perhaps the stereotype should extend the metaclass 'PrimitiveType' instead of 'String'. Refer to Fig 7.13 of the superspec. Michael, can you make this change" Yes, but I'm not sure this is an improvement, why? Some of the vendors need to make no change, and just treat this as a string. Others, could just change how they do string (as there are no rules forbidding them from doing with String what they should do with the new type). By making the stereotype off of a string, I think we give them more freedom, and less duplicate code. Michael -----Original Message----- From: Friedenthal, Sanford Sent: Saturday, July 18, 2009 10:29 AM To: Bock, Conrad; Chonoles, Michael J; Eldad Palachi; Tim Weilkiens; BERNARD, Yves Cc: 'sysml-rtf@omg.org' Subject: RE: partial draft of Ballot 3 available for discussion Roger I am hoping Yves/Tim, Michael and Eldad can make some adjustments to our proposals prior to issuing the ballot, including some of the issues Conrad raises below against flow port decomp, the partition construct, and parsed text, and and some of the comments I have provided flow port decomp and the partition concept. Yves/Tim, Michael, and Eldad, can you please respond to these concerns as noted below and the comments I provided separately. We need to get this resolved right away in order to get on the ballot. THANKS. Conrad The comments you refer to on 'Issue 13178: Port Decompostion and Flow Specification' seemed to apply to the general concept of flow ports and flow specifications rather than the specifics of this proposal. For example, the following statement is directed more generally and has little to do with our specific proposal for allowing a flow specification to be decomposed. "Multiple types of things flowing can be supported with atomic flow ports by defining a supertype of the multiple kinds of this flow, and using that single type for the atomic flow port. The current flow spec model doesn't scale, and in the long run will only be understandable by SysML "hackers", rather than actual systems engineers. Non-atomic flow ports are misleading even in the simple cases, such as the position and speed example, where the non-atomic port can be easily misread as saying speed and position must always flow together. " I do not agree that we should connect flow properties. This has been a source of confusion. In particular, there is confusion between the concept of the port as a connection point, and the flow property which represents the item that is relayed by the port. I have recommended that we connect ports and not flow properties. I would like to discuss this with you if you have time. Eldad, can you review the proposal and see if any adjustments can be made to address Conrads concerns. I would like to discuss this issue about connecting flow properties with whoever is interested, in addition to Conrad. Relative to 'Issue 13928: partition construct' the inconsistencies should be cleaned up. Yves or Tim, can respond to these issues along with the additional comments that I submitted (which have not been circulated to the RTF as a whole). Relative to 'Issue 13939: Parsing Text in Requirements', perhaps the stereotype should extend the metaclass 'PrimitiveType' instead of 'String'. Refer to Fig 7.13 of the superspec. Michael, can you make this change. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Saturday, July 18, 2009 10:04 AM To: 'sysml-rtf@omg.org' Subject: RE: partial draft of Ballot 3 available for discussion Roger, et al, Here are my comments on draft ballot 3 as it's currently posted (except for 13928). Sorry I won't be able to reply to comments very quickly, probably not until the weekend. My sense is the issues addressed here are a bit too much for a last ballot. Conrad - Issue 13178: Port Decomposition of a Flow Specification This resolution is burdensome to use because of the alternatings flow specs and nested ports that potentially have flow specs. It shows that supporting for multiple types of things flowing (non-atomic flow ports) is not worth the complication, especially when integrated with other functionality as this issue is attempting. Multiple types of things flowing can be supported with atomic flow ports by defining a supertype of the multiple kinds of this flow, and using that single type for the atomic flow port. The current flow spec model doesn't scale, and in the long run will only be understandable by SysML "hackers", rather than actual systems engineers. Non-atomic flow ports are misleading even in the simple cases, such as the position and speed example, where the non-atomic port can be easily misread as saying speed and position must always flow together. It is simpler to make a superclass of the Position and Speed (VelocityAspect) as the type of an atomic port. It is isn't even clear it is good system design to send two different kinds of information into the same port, rather than use separate ones. My suggestion would be to simplify the flow spec model before resolving this issue. In the resolution text, point 2, the restriction that flow properties cannot be linked by connectors should be removed. Modelers might want to do this to establish relationships between the things flowing. One example is mentioned in point 4 of the resolution text. - Issue 13928: partition construct I'm assuming the resolution in the draft ballot posted in the wiki is not the currently ballot (which seemed very inconsistent, eg, basing a stereotype on package when the resolution text said it shouldn't). These comments on on the one sent by Yves on Friday, July 17th. Do not use the term "group", at least not without an adjective (as in ActivityGroup). The figures are using different terminology than the text, eg "partition" instead of "attribute". The revised text changes the base class of View from Package to Constraint, is that intentional? If the base class is Constraint, then no additional stereotype is needed. Constraints in UML can already apply to multiple elements of any kind, and has a notation. If a new presentation options is desired, it can be defined directly on UML Constraint, without a stereotype. - Issue 13939: Parsing Text in Requirements This resolution shouldn't depend on a particular language, like HTML. It should take the approach of the rest of UML/SysML is used a multi-valued language tag to indicate the languages used in the markup. My suggestion is for a stereotype to introduce a language attribute. Modelers can specify HTML or other languages. BTW, are you sure String is a metaclass in UML? It appears in the primitive types section with the "primitive" keyword. I don't know whether it can be extended with a stereotype or not. Date: Sat, 18 Jul 2009 18:44:44 -0400 From: "Chonoles, Michael J" Subject: RE: parsed text comments To: "Friedenthal, Sanford" , Burkhart Roger M Cc: sysml-rtf@omg.org Thread-Topic: parsed text comments Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQDOZhZAAAA4zHAACNiGoAAAvynwAAhhfSA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Jul 2009 22:47:17.0836 (UTC) FILETIME=[B3CE18C0:01CA07F9] Sandy. the way I had left it, it would default to html, but accept any other form of markup language if the text of the field started with the correct header for that markup language. Roger, let me see what you've done to it. Michael -----Original Message----- From: Friedenthal, Sanford Sent: Saturday, July 18, 2009 2:45 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: parsed text comments Michael In follow-up discussions with Roger this morning, I think we can leave this as a stereotype of string (which is a PrimitiveType). However, Roger is going to generalize the resolution to be less restrictive on the type of markup language to address Conrad's other concerns. -----Original Message----- From: Chonoles, Michael J Sent: Saturday, July 18, 2009 2:36 PM To: Friedenthal, Sanford Cc: sysml-rtf@omg.org Subject: RE: partial draft of Ballot 3 available for discussion Sandy "Relative to 'Issue 13939: Parsing Text in Requirements', perhaps the stereotype should extend the metaclass 'PrimitiveType' instead of 'String'. Refer to Fig 7.13 of the superspec. Michael, can you make this change" Yes, but I'm not sure this is an improvement, why? Some of the vendors need to make no change, and just treat this as a string. Others, could just change how they do string (as there are no rules forbidding them from doing with String what they should do with the new type). By making the stereotype off of a string, I think we give them more freedom, and less duplicate code. Michael -----Original Message----- From: Friedenthal, Sanford Sent: Saturday, July 18, 2009 10:29 AM To: Bock, Conrad; Chonoles, Michael J; Eldad Palachi; Tim Weilkiens; BERNARD, Yves Cc: 'sysml-rtf@omg.org' Subject: RE: partial draft of Ballot 3 available for discussion Roger I am hoping Yves/Tim, Michael and Eldad can make some adjustments to our proposals prior to issuing the ballot, including some of the issues Conrad raises below against flow port decomp, the partition construct, and parsed text, and and some of the comments I have provided flow port decomp and the partition concept. Yves/Tim, Michael, and Eldad, can you please respond to these concerns as noted below and the comments I provided separately. We need to get this resolved right away in order to get on the ballot. THANKS. Conrad The comments you refer to on 'Issue 13178: Port Decompostion and Flow Specification' seemed to apply to the general concept of flow ports and flow specifications rather than the specifics of this proposal. For example, the following statement is directed more generally and has little to do with our specific proposal for allowing a flow specification to be decomposed. "Multiple types of things flowing can be supported with atomic flow ports by defining a supertype of the multiple kinds of this flow, and using that single type for the atomic flow port. The current flow spec model doesn't scale, and in the long run will only be understandable by SysML "hackers", rather than actual systems engineers. Non-atomic flow ports are misleading even in the simple cases, such as the position and speed example, where the non-atomic port can be easily misread as saying speed and position must always flow together. " I do not agree that we should connect flow properties. This has been a source of confusion. In particular, there is confusion between the concept of the port as a connection point, and the flow property which represents the item that is relayed by the port. I have recommended that we connect ports and not flow properties. I would like to discuss this with you if you have time. Eldad, can you review the proposal and see if any adjustments can be made to address Conrads concerns. I would like to discuss this issue about connecting flow properties with whoever is interested, in addition to Conrad. Relative to 'Issue 13928: partition construct' the inconsistencies should be cleaned up. Yves or Tim, can respond to these issues along with the additional comments that I submitted (which have not been circulated to the RTF as a whole). Relative to 'Issue 13939: Parsing Text in Requirements', perhaps the stereotype should extend the metaclass 'PrimitiveType' instead of 'String'. Refer to Fig 7.13 of the superspec. Michael, can you make this change. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Saturday, July 18, 2009 10:04 AM To: 'sysml-rtf@omg.org' Subject: RE: partial draft of Ballot 3 available for discussion Roger, et al, Here are my comments on draft ballot 3 as it's currently posted (except for 13928). Sorry I won't be able to reply to comments very quickly, probably not until the weekend. My sense is the issues addressed here are a bit too much for a last ballot. Conrad - Issue 13178: Port Decomposition of a Flow Specification This resolution is burdensome to use because of the alternatings flow specs and nested ports that potentially have flow specs. It shows that supporting for multiple types of things flowing (non-atomic flow ports) is not worth the complication, especially when integrated with other functionality as this issue is attempting. Multiple types of things flowing can be supported with atomic flow ports by defining a supertype of the multiple kinds of this flow, and using that single type for the atomic flow port. The current flow spec model doesn't scale, and in the long run will only be understandable by SysML "hackers", rather than actual systems engineers. Non-atomic flow ports are misleading even in the simple cases, such as the position and speed example, where the non-atomic port can be easily misread as saying speed and position must always flow together. It is simpler to make a superclass of the Position and Speed (VelocityAspect) as the type of an atomic port. It is isn't even clear it is good system design to send two different kinds of information into the same port, rather than use separate ones. My suggestion would be to simplify the flow spec model before resolving this issue. In the resolution text, point 2, the restriction that flow properties cannot be linked by connectors should be removed. Modelers might want to do this to establish relationships between the things flowing. One example is mentioned in point 4 of the resolution text. - Issue 13928: partition construct I'm assuming the resolution in the draft ballot posted in the wiki is not the currently ballot (which seemed very inconsistent, eg, basing a stereotype on package when the resolution text said it shouldn't). These comments on on the one sent by Yves on Friday, July 17th. Do not use the term "group", at least not without an adjective (as in ActivityGroup). The figures are using different terminology than the text, eg "partition" instead of "attribute". The revised text changes the base class of View from Package to Constraint, is that intentional? If the base class is Constraint, then no additional stereotype is needed. Constraints in UML can already apply to multiple elements of any kind, and has a notation. If a new presentation options is desired, it can be defined directly on UML Constraint, without a stereotype. - Issue 13939: Parsing Text in Requirements This resolution shouldn't depend on a particular language, like HTML. It should take the approach of the rest of UML/SysML is used a multi-valued language tag to indicate the languages used in the markup. My suggestion is for a stereotype to introduce a language attribute. Modelers can specify HTML or other languages. BTW, are you sure String is a metaclass in UML? It appears in the primitive types section with the "primitive" keyword. I don't know whether it can be extended with a stereotype or not. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Sun, 19 Jul 2009 16:44:50 -0400 Subject: RE: parsed text comments Thread-Topic: parsed text comments Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQDOZhZAAAA4zHAACNiGoAAAvynwAAhhfSAALhSdcA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n6JKfOoD020619 Michael, > Sandy. the way I had left it, it would default to html, but accept > any other form of markup language if the text of the field started > with the correct header for that markup language. In that case, no stereotype is needed. Tools just look at any string to check for the header. No need to distinguish the markedup ones from the others. I have a general concern that introducing a stereotype for this forces changes in all (meta) models that want to use marked up strings. They already can use them, and tools can already recognize them. Conrad Date: Sun, 19 Jul 2009 19:40:42 -0400 From: "Chonoles, Michael J" Subject: RE: parsed text comments To: "Bock, Conrad" , sysml-rtf@omg.org Thread-Topic: parsed text comments Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQDOZhZAAAA4zHAACNiGoAAAvynwAAhhfSAALhSdcAAF59EA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 19 Jul 2009 23:48:22.0030 (UTC) FILETIME=[663F7AE0:01CA08CB] Conrad, you're confusing what tools are doing with what they are being required to do. We're requiring them to pass the entire string through and to observe what markup they can, and to support references to external and internal locations. Not all tools do this at this moment. They are welcome to do it for all strings, but we're requiring this to be done for requirements text and for viewpoint text (and modeler uses of the stereotype string) My original approach was a type based on string, but people preferred the stereotype. Go figure! Michael -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Sunday, July 19, 2009 4:45 PM To: sysml-rtf@omg.org Subject: RE: parsed text comments Michael, > Sandy. the way I had left it, it would default to html, but accept > any other form of markup language if the text of the field started > with the correct header for that markup language. In that case, no stereotype is needed. Tools just look at any string to check for the header. No need to distinguish the markedup ones from the others. I have a general concern that introducing a stereotype for this forces changes in all (meta) models that want to use marked up strings. They already can use them, and tools can already recognize them. Conrad X-Trace: 234189138/mk-outboundfilter-2.mail.uk.tiscali.com/F2S/$F2S-NILDRAM-ACCEPTED/f2s-nildram-customers/84.12.98.161/None/david.price@eurostep.com X-SBRS: None X-RemoteIP: 84.12.98.161 X-IP-MAIL-FROM: david.price@eurostep.com X-SMTP-AUTH: X-MUA: Evolution 2.26.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoABACvPY0pUDGKh/2dsb2JhbAAIvnIJjWyCTIFABQ X-IronPort-AV: E=Sophos;i="4.43,233,1246834800"; d="scan'208";a="234189138" X-IP-Direction: IN Subject: RE: parsed text comments From: David Price Reply-To: david.price@eurostep.com To: "Chonoles, Michael J" Cc: "Bock, Conrad" , sysml-rtf@omg.org Organization: Eurostep Date: Mon, 20 Jul 2009 10:03:17 +0100 X-Mailer: Evolution 2.26.1 Sounds to me like what's being suggested is that these two uses of String in the metamodel should actually be uses of OpaqueExpression. If that was the result, one could use it to specify property-based requirements too. Cheers, David On Sun, 2009-07-19 at 19:40 -0400, Chonoles, Michael J wrote: > Conrad, you're confusing what tools are doing with what they are being > required to do. We're requiring them to pass the entire string through > and to observe what markup they can, and to support references to > external and internal locations. Not all tools do this at this moment. > They are welcome to do it for all strings, but we're requiring this to > be done for requirements text and for viewpoint text (and modeler uses > of the stereotype string) > > My original approach was a type based on string, but people preferred > the stereotype. Go figure! > > Michael > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: Sunday, July 19, 2009 4:45 PM > To: sysml-rtf@omg.org > Subject: RE: parsed text comments > > Michael, > > > Sandy. the way I had left it, it would default to html, but accept > > any other form of markup language if the text of the field started > > with the correct header for that markup language. > > In that case, no stereotype is needed. Tools just look at any string to > check for the header. No need to distinguish the markedup ones from the > others. > > I have a general concern that introducing a stereotype for this forces > changes in all (meta) models that want to use marked up strings. They > already can use them, and tools can already recognize them. > > Conrad -- UK +44 20 8747 3900 Mobile +44 7788 561308 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ.