Issue 6217: UML 2 Super/pg.95/attributes in data types clarification (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Clarification Severity: Summary: pg. 95: DataType::ownedAttribute – is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Resolution: Revised Text: Actions taken: September 7, 2003: received issue March 9, 2005: closed issue Discussion: The UML2 Superstructure (ptc/03-08-02, section 7.12.1, page 95) and UML2 Infrastructure (ptc/03-09-15, section 11.5.1, page 133-134) specifications already indicate that Datatypes may optionally be record types, but do not explicitly call them such. The text reads “A DataType may also contain attributes to support modeling of structured data types” and “If a data type has attributes, then instances of that data type will contain attribute values matching the attributes.” Disposition: Closed, no change End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/pg.95/attributes in data types clarification X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:50:27 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:50:30, Serialize complete at 09/07/2003 09:50:30 pg. 95: DataType::ownedAttribute Ž¶ is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Subject: ,cl, Issue 6217 opinions? Date: Thu, 10 Jun 2004 11:45:07 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPGwxlKD70EeeBSRm/thZdG2463g== From: "Tolbert, Doug M" To: , X-OriginalArrivalTime: 10 Jun 2004 18:45:07.0966 (UTC) FILETIME=[0D55E1E0:01C44F1B] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5AIo4un018327 Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Subject: RE: ,cl, Issue 6217 opinions? Date: Thu, 10 Jun 2004 14:33:21 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPGwxlKD70EeeBSRm/thZdG2463gAFvx4Q From: "Pidcock, Woody" To: "Tolbert, Doug M" , , X-OriginalArrivalTime: 10 Jun 2004 21:33:22.0459 (UTC) FILETIME=[8E1F46B0:01C44F32] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5ALcLun020534 Doug, Question of clarification regarding (1). If a Datatype instance, like "wchar" has a Property named "numBits", does this mean that there could be multiple Datatypes named "wchar", one for each different value of "numBits"? -Woody -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 11:45 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. To: "Tolbert, Doug M" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Issue 6217 opinions? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Thu, 10 Jun 2004 16:04:06 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF342 | June 4, 2004) at 06/10/2004 17:04:09, Serialize complete at 06/10/2004 17:04:09 Doug, These aren't really Properties, they are Annotations or Constraints on a DataType. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/10/2004 11:45 AM To: , cc: Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Subject: RE: ,cl, Issue 6217 opinions? Date: Thu, 10 Jun 2004 16:13:11 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPP0HynNawakLISIm+LT7qBkUU0wAAPulA From: "Tolbert, Doug M" To: "Stephen Brodsky" Cc: , X-OriginalArrivalTime: 10 Jun 2004 23:13:11.0767 (UTC) FILETIME=[80072670:01C44F40] Maybe so, but I'm sort of worried that there will be a strong temptation to use them as I've done. Unless, of course, we advise against it -- which can certainly be done. -----Original Message----- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Thursday, June 10, 2004 4:04 PM To: Tolbert, Doug M Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Issue 6217 opinions? Doug, These aren't really Properties, they are Annotations or Constraints on a DataType. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/10/2004 11:45 AM To: , cc: Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. To: "Tolbert, Doug M" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Thu, 10 Jun 2004 16:43:01 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF342 | June 4, 2004) at 06/10/2004 17:43:03, Serialize complete at 06/10/2004 17:43:03 Doug, Let's advise against it - Properties are not strictly correct and will lead to a lot of confusion both in comparison to annotations & constraints (when do you use A vs B) and also in instantiation. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/10/2004 04:13 PM To: Stephen Brodsky/Santa Teresa/IBM@IBMUS cc: , Subject: RE: ,cl, Issue 6217 opinions? Maybe so, but I'm sort of worried that there will be a strong temptation to use them as I've done. Unless, of course, we advise against it -- which can certainly be done. -----Original Message----- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Thursday, June 10, 2004 4:04 PM To: Tolbert, Doug M Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Issue 6217 opinions? Doug, These aren't really Properties, they are Annotations or Constraints on a DataType. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/10/2004 11:45 AM To: , cc: Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Jun 2004 21:13:13 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: Re: ,cl, Issue 6217 opinions? These aren't really Properties, they are Annotations or Constraints on a DataType. I'm not sure that is true. If a datatype, say CharacterString, had which indicated the number of bits in the string, then each characterString could have a different value for that , or some characterStrings could have the value 8 and others 16. This is exactly a property, isn't it? It is not a constraint, which would apply to all characterStrings Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Jun 2004 21:13:13 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: Re: ,cl, Issue 6217 opinions? These aren't really Properties, they are Annotations or Constraints on a DataType. I'm not sure that is true. If a datatype, say CharacterString, had which indicated the number of bits in the string, then each characterString could have a different value for that , or some characterStrings could have the value 8 and others 16. This is exactly a property, isn't it? It is not a constraint, which would apply to all characterStrings Subject: RE: ,cl, Issue 6217 opinions? Date: Fri, 11 Jun 2004 04:41:29 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPRpt4Lk1qq/ciS+yPimIKYugOXgARyL6A From: "Pete Rivett" To: "Stephen Brodsky" , "Tolbert, Doug M" Cc: , Both DataType and Class inherit from Classifier. The distinction is the common OO one of whether instances are pure value or objects (with an identity distinct from the values of its Properties). So in C++ terms a DataType is a Struct as opposed to a Class. So I agree with Steve we should not encourage usage 1) and with Doug that we could add something explaining usage 2). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Friday, June 11, 2004 12:43 AM To: Tolbert, Doug M Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Doug, Let's advise against it - Properties are not strictly correct and will lead to a lot of confusion both in comparison to annotations & constraints (when do you use A vs B) and also in instantiation. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/10/2004 04:13 PM To: Stephen Brodsky/Santa Teresa/IBM@IBMUS cc: , Subject: RE: ,cl, Issue 6217 opinions? Maybe so, but I'm sort of worried that there will be a strong temptation to use them as I've done. Unless, of course, we advise against it -- which can certainly be done. -----Original Message----- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Thursday, June 10, 2004 4:04 PM To: Tolbert, Doug M Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Issue 6217 opinions? Doug, These aren't really Properties, they are Annotations or Constraints on a DataType. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/10/2004 11:45 AM To: , cc: Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. From: Randall Hauch To: "'Tolbert, Doug M'" , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Date: Fri, 11 Jun 2004 09:05:28 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) I have a use case that may apply here, and it stems from the world of modeling logical/enterprise datatypes in UML but capturing enough information to generate XML Schemas from that UML. Consider a "price" datatype that extends "float", and an "internationalPrice" that extends "Price" but adds a string property for the "currency". "InternationalPrice" is known as a qualified type, since it extends another (simple) type but has additional qualifiers. In XSD, this is very well represented by the following (see http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): Note that "Price" turns out to be represented as a complex type but with simple content. In other words, it's something between a typical complex type (very well modeled in UML with Class), and a simple type (very well modeled in UML with DataType). In my view, it's a DataType that has some qualifying Properties. I've been working with quite a few very XSD- and UML-savvy customers that want to be able to capture this distinction in their UML models, and have to resort to using stereotypes. -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 1:45 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ---------------------------------------------------------------------------- -------- THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Subject: RE: ,cl, Issue 6217 opinions? Date: Mon, 14 Jun 2004 10:53:40 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPvWGx3LIYnZszSySzPKHaStDD8wCeQu8w From: "Pidcock, Woody" To: "Randall Hauch" , "Tolbert, Doug M" , , X-OriginalArrivalTime: 14 Jun 2004 17:53:41.0463 (UTC) FILETIME=[8749E670:01C45238] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5EHx0un001345 This example, with currency, is a good one. In my (hypothetical) application I process purchase orders. Price is one of the fields. It is specified as having a data type of Float (since I used to be a FORTRAN programmer, I will say double-precision float number). The units of this number can be assumed to be US dollars since I do business primarily in the USA. However, some purchase orders may come in from another country and there may be some question regarding the currency of the price value. E.g., Canadian dollars are not the same as US dollars. Please note that chaning the currency property (from US dollars to Canadian dollars) on price does not change the specification of the price field as a double precision float number. However, in a previous example, changing the number of characters in a string specfication from 8 to 16 does change the datatype. I think support for compound datatypes like price+currency is good. I think support for separate datatypes like string8 and string16 (or double precision float) are OK. I think trying to support string as a datatype with a variable length property is bad. -Woody -----Original Message----- From: Randall Hauch [mailto:rhauch@metamatrix.com] Sent: Friday, June 11, 2004 7:05 AM To: 'Tolbert, Doug M'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? I have a use case that may apply here, and it stems from the world of modeling logical/enterprise datatypes in UML but capturing enough information to generate XML Schemas from that UML. Consider a "price" datatype that extends "float", and an "internationalPrice" that extends "Price" but adds a string property for the "currency". "InternationalPrice" is known as a qualified type, since it extends another (simple) type but has additional qualifiers. In XSD, this is very well represented by the following (see http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): Note that "Price" turns out to be represented as a complex type but with simple content. In other words, it's something between a typical complex type (very well modeled in UML with Class), and a simple type (very well modeled in UML with DataType). In my view, it's a DataType that has some qualifying Properties. I've been working with quite a few very XSD- and UML-savvy customers that want to be able to capture this distinction in their UML models, and have to resort to using stereotypes. -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 1:45 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ---------------------------------------------------------------------------- -------- THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Subject: RE: ,cl, Issue 6217 opinions? Date: Mon, 14 Jun 2004 10:54:47 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPGwxlKD70EeeBSRm/thZdG2463gAFvx4QAAGW4+AAA5zfQAC8M40w From: "Tolbert, Doug M" To: "Pidcock, Woody" Cc: "Pete Rivett (E-mail)" , "Steve Brodsky (E-mail)" , , X-OriginalArrivalTime: 14 Jun 2004 17:54:47.0817 (UTC) FILETIME=[AED6B790:01C45238] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5EI00un001378 Woody, I understand your complaint; a user would have to be cognizant of how the Datatype instances owning Properties were used to make sense out of the situation. I'm not arguing that (1) is necessarily a good idea, but rather that the metamodel as defined allows for the possibility of Datatypes that own Properties to be used in the fashion I illustrated in (1). So, based on your concerns, my concerns, and other comments to the reflector by Steve and Pete, I'll cast the resolution to encourage (2) and discourage (1). Doug -----Original Message----- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Thursday, June 10, 2004 5:04 PM To: Tolbert, Doug M Subject: RE: ,cl, Issue 6217 opinions? My "objection" is not limited to your choice of an example. It applies in general. If a Datatype instance "X" has a Property named "Y", how do we refer to a specific instance of Datatype instance "X" (note 2 levels of reification!), where different instances of "X" have different values for "Y"? -Woody -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 3:30 PM To: Pidcock, Woody Subject: RE: ,cl, Issue 6217 opinions? Woody, If I read the Semantics for Namespace (page 37) correctly, full signatures can be used to determine uniqueness within an owning namespace. However, I don't think the presence of individual owned attributes qualifies under this definition. So, I think there can be one "wchar" per owning namespace -- presence of an attribute like "numBits" is not involved in determining namespace uniqueness. It's just an example that occurred to me as I was typing the email, so I make no claims about it being fully baked. The point of (1) is that attributes of DataTypes can be used to store metadata about the type itself. I do hope that this intent is clear even if the example I chose is suboptimal; if not, please complain more. Doug -----Original Message----- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Thursday, June 10, 2004 2:33 PM To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Doug, Question of clarification regarding (1). If a Datatype instance, like "wchar" has a Property named "numBits", does this mean that there could be multiple Datatypes named "wchar", one for each different value of "numBits"? -Woody -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 11:45 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Subject: RE: ,cl, Issue 6217 opinions? Date: Mon, 14 Jun 2004 10:57:34 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPvWGx3LIYnZszSySzPKHaStDD8wCeQu8wAACf06A= From: "Tolbert, Doug M" To: "Pidcock, Woody" , "Randall Hauch" , , X-OriginalArrivalTime: 14 Jun 2004 17:57:34.0727 (UTC) FILETIME=[12532970:01C45239] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5EI2dun001438 Ah, I see this discussion isn't over yet ... So I'm going to postpone drafting a resolution for a bit to see how things develop ... Doug -----Original Message----- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Monday, June 14, 2004 10:54 AM To: Randall Hauch; Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? This example, with currency, is a good one. In my (hypothetical) application I process purchase orders. Price is one of the fields. It is specified as having a data type of Float (since I used to be a FORTRAN programmer, I will say double-precision float number). The units of this number can be assumed to be US dollars since I do business primarily in the USA. However, some purchase orders may come in from another country and there may be some question regarding the currency of the price value. E.g., Canadian dollars are not the same as US dollars. Please note that chaning the currency property (from US dollars to Canadian dollars) on price does not change the specification of the price field as a double precision float number. However, in a previous example, changing the number of characters in a string specfication from 8 to 16 does change the datatype. I think support for compound datatypes like price+currency is good. I think support for separate datatypes like string8 and string16 (or double precision float) are OK. I think trying to support string as a datatype with a variable length property is bad. -Woody -----Original Message----- From: Randall Hauch [mailto:rhauch@metamatrix.com] Sent: Friday, June 11, 2004 7:05 AM To: 'Tolbert, Doug M'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? I have a use case that may apply here, and it stems from the world of modeling logical/enterprise datatypes in UML but capturing enough information to generate XML Schemas from that UML. Consider a "price" datatype that extends "float", and an "internationalPrice" that extends "Price" but adds a string property for the "currency". "InternationalPrice" is known as a qualified type, since it extends another (simple) type but has additional qualifiers. In XSD, this is very well represented by the following (see http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): Note that "Price" turns out to be represented as a complex type but with simple content. In other words, it's something between a typical complex type (very well modeled in UML with Class), and a simple type (very well modeled in UML with DataType). In my view, it's a DataType that has some qualifying Properties. I've been working with quite a few very XSD- and UML-savvy customers that want to be able to capture this distinction in their UML models, and have to resort to using stereotypes. -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 1:45 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ---------------------------------------------------------------------------- -------- THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. To: "Tolbert, Doug M" Cc: mu2i-ftf@omg.org, "Pete Rivett (E-mail)" , uml2-superstructure-ftf@omg.org, "Pidcock, Woody" Subject: RE: ,cl, Issue 6217 opinions? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Mon, 14 Jun 2004 16:36:58 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF342 | June 4, 2004) at 06/14/2004 17:37:16, Serialize complete at 06/14/2004 17:37:16 Doug, I also agree w/Woody's emails - the approach 2 is preferred. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/14/2004 10:54 AM To: "Pidcock, Woody" cc: "Pete Rivett (E-mail)" , Stephen Brodsky/Santa Teresa/IBM@IBMUS, , Subject: RE: ,cl, Issue 6217 opinions? Woody, I understand your complaint; a user would have to be cognizant of how the Datatype instances owning Properties were used to make sense out of the situation. I'm not arguing that (1) is necessarily a good idea, but rather that the metamodel as defined allows for the possibility of Datatypes that own Properties to be used in the fashion I illustrated in (1). So, based on your concerns, my concerns, and other comments to the reflector by Steve and Pete, I'll cast the resolution to encourage (2) and discourage (1). Doug -----Original Message----- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Thursday, June 10, 2004 5:04 PM To: Tolbert, Doug M Subject: RE: ,cl, Issue 6217 opinions? My "objection" is not limited to your choice of an example. It applies in general. If a Datatype instance "X" has a Property named "Y", how do we refer to a specific instance of Datatype instance "X" (note 2 levels of reification!), where different instances of "X" have different values for "Y"? -Woody -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 3:30 PM To: Pidcock, Woody Subject: RE: ,cl, Issue 6217 opinions? Woody, If I read the Semantics for Namespace (page 37) correctly, full signatures can be used to determine uniqueness within an owning namespace. However, I don't think the presence of individual owned attributes qualifies under this definition. So, I think there can be one "wchar" per owning namespace -- presence of an attribute like "numBits" is not involved in determining namespace uniqueness. It's just an example that occurred to me as I was typing the email, so I make no claims about it being fully baked. The point of (1) is that attributes of DataTypes can be used to store metadata about the type itself. I do hope that this intent is clear even if the example I chose is suboptimal; if not, please complain more. Doug -----Original Message----- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Thursday, June 10, 2004 2:33 PM To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Doug, Question of clarification regarding (1). If a Datatype instance, like "wchar" has a Property named "numBits", does this mean that there could be multiple Datatypes named "wchar", one for each different value of "numBits"? -Woody -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 11:45 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. e-mail: bselic@ca.ibm.com Subject: RE: ,cl, Issue 6217 opinions? Date: Thu, 17 Jun 2004 10:27:38 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRPvWDbtZ0Ky00lQ4q6T6ZGq0GhhgE0mp+A From: "Tolbert, Doug M" To: "Randall Hauch" , , X-OriginalArrivalTime: 17 Jun 2004 17:27:38.0544 (UTC) FILETIME=[62F4A300:01C45490] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5HHXSun019028 Randall, Thanks for the example. The general flow of the discussion so far as been to discourage this kind of usage for properties owned by DataTypes. Do you see a way that dependencies or annotations or some other UML constructs can be used to accomplish the intent of the use case you provide? If so, I'll plan on continuing to discourage this kind of usage in the resolution. If not, maybe the discussion needs to continue a bit. Doug -----Original Message----- From: Randall Hauch [mailto:rhauch@metamatrix.com] Sent: Friday, June 11, 2004 7:05 AM To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? I have a use case that may apply here, and it stems from the world of modeling logical/enterprise datatypes in UML but capturing enough information to generate XML Schemas from that UML. Consider a "price" datatype that extends "float", and an "internationalPrice" that extends "Price" but adds a string property for the "currency". "InternationalPrice" is known as a qualified type, since it extends another (simple) type but has additional qualifiers. In XSD, this is very well represented by the following (see http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): Note that "Price" turns out to be represented as a complex type but with simple content. In other words, it's something between a typical complex type (very well modeled in UML with Class), and a simple type (very well modeled in UML with DataType). In my view, it's a DataType that has some qualifying Properties. I've been working with quite a few very XSD- and UML-savvy customers that want to be able to capture this distinction in their UML models, and have to resort to using stereotypes. -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 1:45 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ---------------------------------------------------------------------------- -------- THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. From: Randall Hauch To: "'Tolbert, Doug M'" , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Date: Thu, 17 Jun 2004 12:57:01 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Unfortunately, this is by far the cleanest and most precise way to represent something like qualified types. All other techniques we've investigated (e.g., annotations, profiles, etc.) fail to have the precision and consistency; they all involve using another much more generic feature in a very specific and consistent way, which never can be relied upon. Modeling them as Classes doesn't really work either, since Class instances have identity whereas data types (including qualified data types, such as an "internationalPrice" of [345.35,Dollars]) do not have identity. In my opinion, this is a very real-world example (as well as justification) of why this usage should be allowed. IMO, I don't even think the spec should discourage this usage. And I guess I don't see the issue as needing the spec to be tightened up, but rather some clarification text needing to be added (perhaps in the Semantics section?). For example, the spec [ad/03-08-02, p. 95] already states: "A data type is a type whose values have no identity (i.e., they are pure values)." and "If a data type has attributes, then instances of that data type will contain attribute values matching the attributes." This last sentence could be augmented with the example. The spec also distinguishes that PrimitiveTypes are "without any relevant substructure (i.e. it has no parts)." [ad/03-08-02, p. 98] The spec may be ambiguous, however, as to whether Enumerations could have substructure (like Attributes or Operations); I can't quite get my head around what such an Enumeration might mean. Randall -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 17, 2004 12:28 PM To: Randall Hauch; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Randall, Thanks for the example. The general flow of the discussion so far as been to discourage this kind of usage for properties owned by DataTypes. Do you see a way that dependencies or annotations or some other UML constructs can be used to accomplish the intent of the use case you provide? If so, I'll plan on continuing to discourage this kind of usage in the resolution. If not, maybe the discussion needs to continue a bit. Doug -----Original Message----- From: Randall Hauch [mailto:rhauch@metamatrix.com] Sent: Friday, June 11, 2004 7:05 AM To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? I have a use case that may apply here, and it stems from the world of modeling logical/enterprise datatypes in UML but capturing enough information to generate XML Schemas from that UML. Consider a "price" datatype that extends "float", and an "internationalPrice" that extends "Price" but adds a string property for the "currency". "InternationalPrice" is known as a qualified type, since it extends another (simple) type but has additional qualifiers. In XSD, this is very well represented by the following (see http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): Note that "Price" turns out to be represented as a complex type but with simple content. In other words, it's something between a typical complex type (very well modeled in UML with Class), and a simple type (very well modeled in UML with DataType). In my view, it's a DataType that has some qualifying Properties. I've been working with quite a few very XSD- and UML-savvy customers that want to be able to capture this distinction in their UML models, and have to resort to using stereotypes. -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 10, 2004 1:45 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Issue 6217 opinions? Folks, I've been stewing over issue 6217 (text appears below) for a while and think I should ask for opinions before proposing a resolution. The issue suggests textually acknowledging that DataTypes can own Properties and thus can be record types. I see a couple of potential uses for DataTypes owning Properties: (1) Properties can be used to record instance-specific meta attributes of the types themselves. While perhaps infrequent, there are some seemingly legitimate uses. One example might entail defining a "numBits" Property for the "wchar" instance of Datatype and setting its default value to 16, permitting an application to "discover" the bit-width of characters rather than having it hardcoded in the application. (2) The definition of record types, as suggested by the issue itself and implied in the current spec. Personally, I like this capability because I tend to think of record types as complex data types. However, one might equally legitimately claim that record types are really instances of Classifer. The latter approach suggests that one thinks of records as more like objects than like datatypes. I suspect both viewpoints are valid given that we want to retain the distinction between DataTypes and Classifiers [IMHO, not having this distinction would certainly simplify the technical situation, but I suspect any suggestion of discarding it at this point would be both contentious and out of scope for an FTF, so I'm not planning on making such a suggestion]. (1) doesn't have any downsides that I'm aware of. The only downside to (2) that I see might involve unexpected results to a query like "get all record types (ie, those that own attributes)". If this query were targeted at DataType, we'd get back all data-type-like records but no object-like records. Conversely, if the query were targeted at Classifier, we'd get back all both kinds of record types. This isn't in principle bad unless the user community is inconsistent in choosing how to store record types. In my view, this is one of the costs of having a distinction between DataType and Classifier. So, I'd suggest a caveat emptor approach to this and propose changing nothing. Anyone want to yell at me about this before I suggest doing what the issue suggests and proposing the addition of text that explicitly points out the capability of defining datatypes that own Properties? Doug -------------------------------------------------------------- OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com ) Summary: pg. 95: DataType::ownedAttribute - is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ---------------------------------------------------------------------------- -------- THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Subject: RE: ,cl, Issue 6217 opinions? Date: Thu, 17 Jun 2004 15:18:47 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRUleKc08zuU+9kSvePFmGsNDC2fgAB83/g From: "Pete Rivett" To: "Randall Hauch" , "Tolbert, Doug M" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5HJEpun020969 I'm a bit confusd as to where this discussion is going. Doug in the original email identified 2 potential uses for Datatype.property. Randall came up with a good use case but did not make it clear which of Doug's 2 uses he was referring to, and came up with a new term 'qualifying properties'. My understanding of his intent is that it falls into Doug's use 2. As other emails have stated I think Doug's use 1 is a bit dodgy and I think the consensus was to discourage it. Doug's potential problem with use 2 is a non-problem as far as I can see - people can always query Classifier instead of DataType/Class. So Randall is your example exploiting use 2, in which case there does not seem to be a problem. Pete BTW there are several other failings in UML/MOF for representing XML structures e,g. unions. I tried in vain to persuade other UML submitters to take this on board as a requirement. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Thursday, June 17, 2004 11:57 AM > To: 'Tolbert, Doug M'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Unfortunately, this is by far the cleanest and most precise > way to represent > something like qualified types. All other techniques we've > investigated > (e.g., annotations, profiles, etc.) fail to have the precision and > consistency; they all involve using another much more generic > feature in a > very specific and consistent way, which never can be relied > upon. Modeling > them as Classes doesn't really work either, since Class instances have > identity whereas data types (including qualified data types, > such as an > "internationalPrice" of [345.35,Dollars]) do not have identity. > > In my opinion, this is a very real-world example (as well as > justification) > of why this usage should be allowed. IMO, I don't even think the spec > should discourage this usage. And I guess I don't see the > issue as needing > the spec to be tightened up, but rather some clarification > text needing to > be added (perhaps in the Semantics section?). For example, the spec > [ad/03-08-02, p. 95] already states: > > "A data type is a type whose values have no identity > (i.e., they are > pure values)." > and > "If a data type has attributes, then instances of that > data type > will contain attribute values matching the attributes." > > This last sentence could be augmented with the example. The spec also > distinguishes that PrimitiveTypes are "without any relevant > substructure > (i.e. it has no parts)." [ad/03-08-02, p. 98] The spec may > be ambiguous, > however, as to whether Enumerations could have substructure > (like Attributes > or Operations); I can't quite get my head around what such an > Enumeration > might mean. > > Randall > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 17, 2004 12:28 PM > To: Randall Hauch; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Randall, > > Thanks for the example. The general flow of the discussion > so far as been > to discourage this kind of usage for properties owned by > DataTypes. Do you > see a way that dependencies or annotations or some other UML > constructs can > be used to accomplish the intent of the use case you provide? > If so, I'll > plan on continuing to discourage this kind of usage in the > resolution. If > not, maybe the discussion needs to continue a bit. > > Doug > > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Friday, June 11, 2004 7:05 AM > To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > > I have a use case that may apply here, and it stems from the world of > modeling logical/enterprise datatypes in UML but capturing enough > information to generate XML Schemas from that UML. > > Consider a "price" datatype that extends "float", and an > "internationalPrice" that extends "Price" but adds a string > property for the > "currency". "InternationalPrice" is known as a qualified > type, since it > extends another (simple) type but has additional qualifiers. > > In XSD, this is very well represented by the following (see > http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): > > > > > > > > > > Note that "Price" turns out to be represented as a complex > type but with > simple content. In other words, it's something between a > typical complex > type (very well modeled in UML with Class), and a simple type > (very well > modeled in UML with DataType). In my view, it's a DataType > that has some > qualifying Properties. I've been working with quite a few > very XSD- and > UML-savvy customers that want to be able to capture this > distinction in > their UML models, and have to resort to using stereotypes. > > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 10, 2004 1:45 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: ,cl, Issue 6217 opinions? > > Folks, > > I've been stewing over issue 6217 (text appears below) for a > while and think > I should ask for opinions before proposing a resolution. The > issue suggests > textually acknowledging that DataTypes can own Properties and > thus can be > record types. > > I see a couple of potential uses for DataTypes owning Properties: > > (1) Properties can be used to record instance-specific meta > attributes of > the types themselves. While perhaps infrequent, there are > some seemingly > legitimate uses. One example might entail defining a > "numBits" Property for > the "wchar" instance of Datatype and setting its default value to 16, > permitting an application to "discover" the bit-width of > characters rather > than having it hardcoded in the application. > > (2) The definition of record types, as suggested by the issue > itself and > implied in the current spec. Personally, I like this > capability because I > tend to think of record types as complex data types. > However, one might > equally legitimately claim that record types are really instances of > Classifer. The latter approach suggests that one thinks of > records as more > like objects than like datatypes. I suspect both viewpoints > are valid given > that we want to retain the distinction between DataTypes and > Classifiers > [IMHO, not having this distinction would certainly simplify > the technical > situation, but I suspect any suggestion of discarding it at > this point would > be both contentious and out of scope for an FTF, so I'm not > planning on > making such a suggestion]. > > (1) doesn't have any downsides that I'm aware of. The only > downside to (2) > that I see might involve unexpected results to a query like > "get all record > types (ie, those that own attributes)". If this query were > targeted at > DataType, we'd get back all data-type-like records but no object-like > records. Conversely, if the query were targeted at > Classifier, we'd get > back all both kinds of record types. This isn't in principle > bad unless the > user community is inconsistent in choosing how to store > record types. In my > view, this is one of the costs of having a distinction > between DataType and > Classifier. So, I'd suggest a caveat emptor approach to this > and propose > changing nothing. > > Anyone want to yell at me about this before I suggest doing > what the issue > suggests and proposing the addition of text that explicitly > points out the > capability of defining datatypes that own Properties? > > Doug > > -------------------------------------------------------------- > OMG Issue No: 6217 > Title: UML 2 Super/pg.95/attributes in data types clarification > Source: > International Business Machines (Mr. Bran Selic, > bselic@ca.ibm.com bselic@ca.ibm.com>) > Summary: > pg. 95: DataType::ownedAttribute - is the intent to permit > record types by > allowing attributes in data types? Maybe should say that > somewhere or give > an example > Discussion: > {IF APPLICABLE - Summary of how the issue was proposed to be > resolved and/or > why it wasn't} > Disposition: Unresolved > > > -------------------------------------------------------------- > -------------- > -------- > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. > If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > From: Randall Hauch To: "'Pete Rivett'" , "Tolbert, Doug M" , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Date: Thu, 17 Jun 2004 15:05:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sorry for not being clear and precise. My term "qualified type" comes from terminology often used in the world of XML Schemas, and I merely applied it to a UML2 DataType that has attributes (properties). I think my scenario _is_ an example of Doug's #2 use case, and so I believe the spec is fine as is. Therefore, I agree with Doug's original proposal to do nothing, or (as Bran suggested in the issue) to add an example of the use case. However, I disagree that with Doug's more recent suggestion: > The general flow of the discussion so far as > been to discourage this kind of usage for properties owned by > DataTypes. Do you see a way that dependencies or annotations or some > other UML constructs can be used to accomplish the intent of the use > case you provide? If so, I'll > plan on continuing to discourage this kind of usage in the resolution. IMO, we should not discourage a usage that satisfies a real-world situations and that appears to be perfectly in line with the existing spec. Does that help? Randall -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, June 17, 2004 2:19 PM To: Randall Hauch; Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? I'm a bit confusd as to where this discussion is going. Doug in the original email identified 2 potential uses for Datatype.property. Randall came up with a good use case but did not make it clear which of Doug's 2 uses he was referring to, and came up with a new term 'qualifying properties'. My understanding of his intent is that it falls into Doug's use 2. As other emails have stated I think Doug's use 1 is a bit dodgy and I think the consensus was to discourage it. Doug's potential problem with use 2 is a non-problem as far as I can see - people can always query Classifier instead of DataType/Class. So Randall is your example exploiting use 2, in which case there does not seem to be a problem. Pete BTW there are several other failings in UML/MOF for representing XML structures e,g. unions. I tried in vain to persuade other UML submitters to take this on board as a requirement. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Thursday, June 17, 2004 11:57 AM > To: 'Tolbert, Doug M'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Unfortunately, this is by far the cleanest and most precise way to > represent something like qualified types. All other techniques we've > investigated (e.g., annotations, profiles, etc.) fail to have the > precision and consistency; they all involve using another much more > generic feature in a very specific and consistent way, which never can > be relied upon. Modeling them as Classes doesn't really work either, > since Class instances have identity whereas data types (including > qualified data types, such as an "internationalPrice" of > [345.35,Dollars]) do not have identity. > > In my opinion, this is a very real-world example (as well as > justification) > of why this usage should be allowed. IMO, I don't even think the spec > should discourage this usage. And I guess I don't see the issue as > needing the spec to be tightened up, but rather some clarification > text needing to be added (perhaps in the Semantics section?). For > example, the spec [ad/03-08-02, p. 95] already states: > > "A data type is a type whose values have no identity (i.e., they are > pure values)." > and > "If a data type has attributes, then instances of that data type > will contain attribute values matching the attributes." > > This last sentence could be augmented with the example. The spec also > distinguishes that PrimitiveTypes are "without any relevant > substructure (i.e. it has no parts)." [ad/03-08-02, p. 98] The spec > may be ambiguous, however, as to whether Enumerations could have > substructure (like Attributes or Operations); I can't quite get my > head around what such an Enumeration might mean. > > Randall > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 17, 2004 12:28 PM > To: Randall Hauch; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Randall, > > Thanks for the example. The general flow of the discussion so far as > been to discourage this kind of usage for properties owned by > DataTypes. Do you see a way that dependencies or annotations or some > other UML constructs can be used to accomplish the intent of the use > case you provide? > If so, I'll > plan on continuing to discourage this kind of usage in the resolution. > If not, maybe the discussion needs to continue a bit. > > Doug > > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Friday, June 11, 2004 7:05 AM > To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > > I have a use case that may apply here, and it stems from the world of > modeling logical/enterprise datatypes in UML but capturing enough > information to generate XML Schemas from that UML. > > Consider a "price" datatype that extends "float", and an > "internationalPrice" that extends "Price" but adds a string property > for the "currency". "InternationalPrice" is known as a qualified > type, since it extends another (simple) type but has additional > qualifiers. > > In XSD, this is very well represented by the following (see > http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): > > > > > > > > > > Note that "Price" turns out to be represented as a complex type but > with simple content. In other words, it's something between a typical > complex type (very well modeled in UML with Class), and a simple type > (very well modeled in UML with DataType). In my view, it's a DataType > that has some qualifying Properties. I've been working with quite a > few very XSD- and UML-savvy customers that want to be able to capture > this distinction in their UML models, and have to resort to using > stereotypes. > > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 10, 2004 1:45 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: ,cl, Issue 6217 opinions? > > Folks, > > I've been stewing over issue 6217 (text appears below) for a while and > think I should ask for opinions before proposing a resolution. The > issue suggests textually acknowledging that DataTypes can own > Properties and thus can be record types. > > I see a couple of potential uses for DataTypes owning Properties: > > (1) Properties can be used to record instance-specific meta attributes > of the types themselves. While perhaps infrequent, there are some > seemingly legitimate uses. One example might entail defining a > "numBits" Property for the "wchar" instance of Datatype and setting > its default value to 16, permitting an application to "discover" the > bit-width of characters rather than having it hardcoded in the > application. > > (2) The definition of record types, as suggested by the issue itself > and implied in the current spec. Personally, I like this capability > because I tend to think of record types as complex data types. > However, one might > equally legitimately claim that record types are really instances of > Classifer. The latter approach suggests that one thinks of records as > more like objects than like datatypes. I suspect both viewpoints are > valid given that we want to retain the distinction between DataTypes > and Classifiers [IMHO, not having this distinction would certainly > simplify the technical situation, but I suspect any suggestion of > discarding it at this point would be both contentious and out of scope > for an FTF, so I'm not planning on making such a suggestion]. > > (1) doesn't have any downsides that I'm aware of. The only downside > to (2) that I see might involve unexpected results to a query like > "get all record types (ie, those that own attributes)". If this query > were targeted at DataType, we'd get back all data-type-like records > but no object-like records. Conversely, if the query were targeted at > Classifier, we'd get back all both kinds of record types. This isn't > in principle bad unless the user community is inconsistent in choosing > how to store record types. In my view, this is one of the costs of > having a distinction between DataType and Classifier. So, I'd suggest > a caveat emptor approach to this and propose changing nothing. > > Anyone want to yell at me about this before I suggest doing what the > issue suggests and proposing the addition of text that explicitly > points out the capability of defining datatypes that own Properties? > > Doug > > -------------------------------------------------------------- > OMG Issue No: 6217 > Title: UML 2 Super/pg.95/attributes in data types clarification > Source: > International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com > bselic@ca.ibm.com>) > Summary: > pg. 95: DataType::ownedAttribute - is the intent to permit record > types by allowing attributes in data types? Maybe should say that > somewhere or give an example > Discussion: > {IF APPLICABLE - Summary of how the issue was proposed to be resolved > and/or why it wasn't} > Disposition: Unresolved > > > -------------------------------------------------------------- > -------------- > -------- > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. > If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > Subject: RE: ,cl, Issue 6217 opinions? Date: Thu, 17 Jun 2004 13:35:22 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6217 opinions? Thread-Index: AcRUpob4uXrSubjATNWDTf4OpYGiRQAA5lXg From: "Tolbert, Doug M" To: "Randall Hauch" , "Pete Rivett" , , X-OriginalArrivalTime: 17 Jun 2004 20:35:22.0791 (UTC) FILETIME=[9CF85370:01C454AA] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5HKequn022281 Well, maybe it's me that's confused. I was operating under the apparently mistaken assumption (obviously resulting from insufficient study on my part) that Randall's use case was an example of my #1. On further reading, I agree that I'm confused. So, #1 is out; #2 is in. I'll draft the resolution accordingly. If you disagree, speak now or vote NO later! Doug -----Original Message----- From: Randall Hauch [mailto:rhauch@metamatrix.com] Sent: Thursday, June 17, 2004 1:06 PM To: 'Pete Rivett'; Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Sorry for not being clear and precise. My term "qualified type" comes from terminology often used in the world of XML Schemas, and I merely applied it to a UML2 DataType that has attributes (properties). I think my scenario _is_ an example of Doug's #2 use case, and so I believe the spec is fine as is. Therefore, I agree with Doug's original proposal to do nothing, or (as Bran suggested in the issue) to add an example of the use case. However, I disagree that with Doug's more recent suggestion: > The general flow of the discussion so far as > been to discourage this kind of usage for properties owned by > DataTypes. Do you see a way that dependencies or annotations or some > other UML constructs can be used to accomplish the intent of the use > case you provide? If so, I'll > plan on continuing to discourage this kind of usage in the resolution. IMO, we should not discourage a usage that satisfies a real-world situations and that appears to be perfectly in line with the existing spec. Does that help? Randall -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, June 17, 2004 2:19 PM To: Randall Hauch; Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? I'm a bit confusd as to where this discussion is going. Doug in the original email identified 2 potential uses for Datatype.property. Randall came up with a good use case but did not make it clear which of Doug's 2 uses he was referring to, and came up with a new term 'qualifying properties'. My understanding of his intent is that it falls into Doug's use 2. As other emails have stated I think Doug's use 1 is a bit dodgy and I think the consensus was to discourage it. Doug's potential problem with use 2 is a non-problem as far as I can see - people can always query Classifier instead of DataType/Class. So Randall is your example exploiting use 2, in which case there does not seem to be a problem. Pete BTW there are several other failings in UML/MOF for representing XML structures e,g. unions. I tried in vain to persuade other UML submitters to take this on board as a requirement. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Thursday, June 17, 2004 11:57 AM > To: 'Tolbert, Doug M'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Unfortunately, this is by far the cleanest and most precise way to > represent something like qualified types. All other techniques we've > investigated (e.g., annotations, profiles, etc.) fail to have the > precision and consistency; they all involve using another much more > generic feature in a very specific and consistent way, which never can > be relied upon. Modeling them as Classes doesn't really work either, > since Class instances have identity whereas data types (including > qualified data types, such as an "internationalPrice" of > [345.35,Dollars]) do not have identity. > > In my opinion, this is a very real-world example (as well as > justification) > of why this usage should be allowed. IMO, I don't even think the spec > should discourage this usage. And I guess I don't see the issue as > needing the spec to be tightened up, but rather some clarification > text needing to be added (perhaps in the Semantics section?). For > example, the spec [ad/03-08-02, p. 95] already states: > > "A data type is a type whose values have no identity (i.e., they are > pure values)." > and > "If a data type has attributes, then instances of that data type > will contain attribute values matching the attributes." > > This last sentence could be augmented with the example. The spec also > distinguishes that PrimitiveTypes are "without any relevant > substructure (i.e. it has no parts)." [ad/03-08-02, p. 98] The spec > may be ambiguous, however, as to whether Enumerations could have > substructure (like Attributes or Operations); I can't quite get my > head around what such an Enumeration might mean. > > Randall > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 17, 2004 12:28 PM > To: Randall Hauch; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Randall, > > Thanks for the example. The general flow of the discussion so far as > been to discourage this kind of usage for properties owned by > DataTypes. Do you see a way that dependencies or annotations or some > other UML constructs can be used to accomplish the intent of the use > case you provide? > If so, I'll > plan on continuing to discourage this kind of usage in the resolution. > If not, maybe the discussion needs to continue a bit. > > Doug > > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Friday, June 11, 2004 7:05 AM > To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > > I have a use case that may apply here, and it stems from the world of > modeling logical/enterprise datatypes in UML but capturing enough > information to generate XML Schemas from that UML. > > Consider a "price" datatype that extends "float", and an > "internationalPrice" that extends "Price" but adds a string property > for the "currency". "InternationalPrice" is known as a qualified > type, since it extends another (simple) type but has additional > qualifiers. > > In XSD, this is very well represented by the following (see > http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): > > > > > > > > > > Note that "Price" turns out to be represented as a complex type but > with simple content. In other words, it's something between a typical > complex type (very well modeled in UML with Class), and a simple type > (very well modeled in UML with DataType). In my view, it's a DataType > that has some qualifying Properties. I've been working with quite a > few very XSD- and UML-savvy customers that want to be able to capture > this distinction in their UML models, and have to resort to using > stereotypes. > > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 10, 2004 1:45 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: ,cl, Issue 6217 opinions? > > Folks, > > I've been stewing over issue 6217 (text appears below) for a while and > think I should ask for opinions before proposing a resolution. The > issue suggests textually acknowledging that DataTypes can own > Properties and thus can be record types. > > I see a couple of potential uses for DataTypes owning Properties: > > (1) Properties can be used to record instance-specific meta attributes > of the types themselves. While perhaps infrequent, there are some > seemingly legitimate uses. One example might entail defining a > "numBits" Property for the "wchar" instance of Datatype and setting > its default value to 16, permitting an application to "discover" the > bit-width of characters rather than having it hardcoded in the > application. > > (2) The definition of record types, as suggested by the issue itself > and implied in the current spec. Personally, I like this capability > because I tend to think of record types as complex data types. > However, one might > equally legitimately claim that record types are really instances of > Classifer. The latter approach suggests that one thinks of records as > more like objects than like datatypes. I suspect both viewpoints are > valid given that we want to retain the distinction between DataTypes > and Classifiers [IMHO, not having this distinction would certainly > simplify the technical situation, but I suspect any suggestion of > discarding it at this point would be both contentious and out of scope > for an FTF, so I'm not planning on making such a suggestion]. > > (1) doesn't have any downsides that I'm aware of. The only downside > to (2) that I see might involve unexpected results to a query like > "get all record types (ie, those that own attributes)". If this query > were targeted at DataType, we'd get back all data-type-like records > but no object-like records. Conversely, if the query were targeted at > Classifier, we'd get back all both kinds of record types. This isn't > in principle bad unless the user community is inconsistent in choosing > how to store record types. In my view, this is one of the costs of > having a distinction between DataType and Classifier. So, I'd suggest > a caveat emptor approach to this and propose changing nothing. > > Anyone want to yell at me about this before I suggest doing what the > issue suggests and proposing the addition of text that explicitly > points out the capability of defining datatypes that own Properties? > > Doug > > -------------------------------------------------------------- > OMG Issue No: 6217 > Title: UML 2 Super/pg.95/attributes in data types clarification > Source: > International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com > bselic@ca.ibm.com>) > Summary: > pg. 95: DataType::ownedAttribute - is the intent to permit record > types by allowing attributes in data types? Maybe should say that > somewhere or give an example > Discussion: > {IF APPLICABLE - Summary of how the issue was proposed to be resolved > and/or why it wasn't} > Disposition: Unresolved > > > -------------------------------------------------------------- > -------------- > -------- > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. > If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > To: "Tolbert, Doug M" Cc: mu2i-ftf@omg.org, "Pete Rivett" , "Randall Hauch" , uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Thu, 17 Jun 2004 16:18:08 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF342 | June 4, 2004) at 06/17/2004 17:18:37, Serialize complete at 06/17/2004 17:18:37 Doug, I think all the examples indicate that its best not to change the spec. I think that is what 2 means, and if so we are all happy with no change. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Tolbert, Doug M" 06/17/2004 01:35 PM To: "Randall Hauch" , "Pete Rivett" , , cc: Subject: RE: ,cl, Issue 6217 opinions? Well, maybe it's me that's confused. I was operating under the apparently mistaken assumption (obviously resulting from insufficient study on my part) that Randall's use case was an example of my #1. On further reading, I agree that I'm confused. So, #1 is out; #2 is in. I'll draft the resolution accordingly. If you disagree, speak now or vote NO later! Doug -----Original Message----- From: Randall Hauch [mailto:rhauch@metamatrix.com] Sent: Thursday, June 17, 2004 1:06 PM To: 'Pete Rivett'; Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? Sorry for not being clear and precise. My term "qualified type" comes from terminology often used in the world of XML Schemas, and I merely applied it to a UML2 DataType that has attributes (properties). I think my scenario _is_ an example of Doug's #2 use case, and so I believe the spec is fine as is. Therefore, I agree with Doug's original proposal to do nothing, or (as Bran suggested in the issue) to add an example of the use case. However, I disagree that with Doug's more recent suggestion: > The general flow of the discussion so far as > been to discourage this kind of usage for properties owned by > DataTypes. Do you see a way that dependencies or annotations or some > other UML constructs can be used to accomplish the intent of the use > case you provide? If so, I'll > plan on continuing to discourage this kind of usage in the resolution. IMO, we should not discourage a usage that satisfies a real-world situations and that appears to be perfectly in line with the existing spec. Does that help? Randall -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, June 17, 2004 2:19 PM To: Randall Hauch; Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cl, Issue 6217 opinions? I'm a bit confusd as to where this discussion is going. Doug in the original email identified 2 potential uses for Datatype.property. Randall came up with a good use case but did not make it clear which of Doug's 2 uses he was referring to, and came up with a new term 'qualifying properties'. My understanding of his intent is that it falls into Doug's use 2. As other emails have stated I think Doug's use 1 is a bit dodgy and I think the consensus was to discourage it. Doug's potential problem with use 2 is a non-problem as far as I can see - people can always query Classifier instead of DataType/Class. So Randall is your example exploiting use 2, in which case there does not seem to be a problem. Pete BTW there are several other failings in UML/MOF for representing XML structures e,g. unions. I tried in vain to persuade other UML submitters to take this on board as a requirement. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Thursday, June 17, 2004 11:57 AM > To: 'Tolbert, Doug M'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Unfortunately, this is by far the cleanest and most precise way to > represent something like qualified types. All other techniques we've > investigated (e.g., annotations, profiles, etc.) fail to have the > precision and consistency; they all involve using another much more > generic feature in a very specific and consistent way, which never can > be relied upon. Modeling them as Classes doesn't really work either, > since Class instances have identity whereas data types (including > qualified data types, such as an "internationalPrice" of > [345.35,Dollars]) do not have identity. > > In my opinion, this is a very real-world example (as well as > justification) > of why this usage should be allowed. IMO, I don't even think the spec > should discourage this usage. And I guess I don't see the issue as > needing the spec to be tightened up, but rather some clarification > text needing to be added (perhaps in the Semantics section?). For > example, the spec [ad/03-08-02, p. 95] already states: > > "A data type is a type whose values have no identity (i.e., they are > pure values)." > and > "If a data type has attributes, then instances of that data type > will contain attribute values matching the attributes." > > This last sentence could be augmented with the example. The spec also > distinguishes that PrimitiveTypes are "without any relevant > substructure (i.e. it has no parts)." [ad/03-08-02, p. 98] The spec > may be ambiguous, however, as to whether Enumerations could have > substructure (like Attributes or Operations); I can't quite get my > head around what such an Enumeration might mean. > > Randall > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 17, 2004 12:28 PM > To: Randall Hauch; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > Randall, > > Thanks for the example. The general flow of the discussion so far as > been to discourage this kind of usage for properties owned by > DataTypes. Do you see a way that dependencies or annotations or some > other UML constructs can be used to accomplish the intent of the use > case you provide? > If so, I'll > plan on continuing to discourage this kind of usage in the resolution. > If not, maybe the discussion needs to continue a bit. > > Doug > > -----Original Message----- > From: Randall Hauch [mailto:rhauch@metamatrix.com] > Sent: Friday, June 11, 2004 7:05 AM > To: Tolbert, Doug M; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: ,cl, Issue 6217 opinions? > > > I have a use case that may apply here, and it stems from the world of > modeling logical/enterprise datatypes in UML but capturing enough > information to generate XML Schemas from that UML. > > Consider a "price" datatype that extends "float", and an > "internationalPrice" that extends "Price" but adds a string property > for the "currency". "InternationalPrice" is known as a qualified > type, since it extends another (simple) type but has additional > qualifiers. > > In XSD, this is very well represented by the following (see > http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT): > > > > > > > > > > Note that "Price" turns out to be represented as a complex type but > with simple content. In other words, it's something between a typical > complex type (very well modeled in UML with Class), and a simple type > (very well modeled in UML with DataType). In my view, it's a DataType > that has some qualifying Properties. I've been working with quite a > few very XSD- and UML-savvy customers that want to be able to capture > this distinction in their UML models, and have to resort to using > stereotypes. > > > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: Thursday, June 10, 2004 1:45 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: ,cl, Issue 6217 opinions? > > Folks, > > I've been stewing over issue 6217 (text appears below) for a while and > think I should ask for opinions before proposing a resolution. The > issue suggests textually acknowledging that DataTypes can own > Properties and thus can be record types. > > I see a couple of potential uses for DataTypes owning Properties: > > (1) Properties can be used to record instance-specific meta attributes > of the types themselves. While perhaps infrequent, there are some > seemingly legitimate uses. One example might entail defining a > "numBits" Property for the "wchar" instance of Datatype and setting > its default value to 16, permitting an application to "discover" the > bit-width of characters rather than having it hardcoded in the > application. > > (2) The definition of record types, as suggested by the issue itself > and implied in the current spec. Personally, I like this capability > because I tend to think of record types as complex data types. > However, one might > equally legitimately claim that record types are really instances of > Classifer. The latter approach suggests that one thinks of records as > more like objects than like datatypes. I suspect both viewpoints are > valid given that we want to retain the distinction between DataTypes > and Classifiers [IMHO, not having this distinction would certainly > simplify the technical situation, but I suspect any suggestion of > discarding it at this point would be both contentious and out of scope > for an FTF, so I'm not planning on making such a suggestion]. > > (1) doesn't have any downsides that I'm aware of. The only downside > to (2) that I see might involve unexpected results to a query like > "get all record types (ie, those that own attributes)". If this query > were targeted at DataType, we'd get back all data-type-like records > but no object-like records. Conversely, if the query were targeted at > Classifier, we'd get back all both kinds of record types. This isn't > in principle bad unless the user community is inconsistent in choosing > how to store record types. In my view, this is one of the costs of > having a distinction between DataType and Classifier. So, I'd suggest > a caveat emptor approach to this and propose changing nothing. > > Anyone want to yell at me about this before I suggest doing what the > issue suggests and proposing the addition of text that explicitly > points out the capability of defining datatypes that own Properties? > > Doug > > -------------------------------------------------------------- > OMG Issue No: 6217 > Title: UML 2 Super/pg.95/attributes in data types clarification > Source: > International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com > bselic@ca.ibm.com>) > Summary: > pg. 95: DataType::ownedAttribute - is the intent to permit record > types by allowing attributes in data types? Maybe should say that > somewhere or give an example > Discussion: > {IF APPLICABLE - Summary of how the issue was proposed to be resolved > and/or why it wasn't} > Disposition: Unresolved > > > -------------------------------------------------------------- > -------------- > -------- > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. > If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > Subject: ,cl, Proposed resolution for shared issue 6217 Date: Fri, 18 Jun 2004 14:08:12 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed resolution for shared issue 6217 Thread-Index: AcRVeFzRW9Cy2UbhQguY0MDJq2P2Cg== From: "Tolbert, Doug M" To: , X-OriginalArrivalTime: 18 Jun 2004 21:08:13.0644 (UTC) FILETIME=[5E1A60C0:01C45578] <> ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Issue 6217 Resolution.doc OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: pg. 95: DataType::ownedAttribute . is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: The UML2 Superstructure (ptc/03-08-02, section 7.12.1, page 95) and UML2 Infrastructure (ptc/03-09-15, section 11.5.1, page 133-134) specifications already indicate that Datatypes may optionally be record types, but do not explicitly call them such. The text reads .A DataType may also contain attributes to support modeling of structured data types. and .If a data type has attributes, then instances of that data type will contain attribute values matching the attributes.. Disposition: Closed, no change Subject: [Resend] ,cl, Proposed resolution for shared issue 6217 Date: Tue, 13 Jul 2004 09:14:44 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed resolution for shared issue 6217 Thread-Index: AcRVeFzRW9Cy2UbhQguY0MDJq2P2CgTe/uIQ From: "Tolbert, Doug M" To: , X-OriginalArrivalTime: 13 Jul 2004 16:14:45.0199 (UTC) FILETIME=[82FAA5F0:01C468F4] This is a resending of the proposed resolution to issue 6217 requested by Bran. Doug OMG Issue No: 6217 Title: UML 2 Super/pg.95/attributes in data types clarification Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: pg. 95: DataType::ownedAttribute . is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example Discussion: The UML2 Superstructure (ptc/03-08-02, section 7.12.1, page 95) and UML2 Infrastructure (ptc/03-09-15, section 11.5.1, page 133-134) specifications already indicate that Datatypes may optionally be record types, but do not explicitly call them such. The text reads .A DataType may also contain attributes to support modeling of structured data types. and .If a data type has attributes, then instances of that data type will contain attribute values matching the attributes.. Disposition: Closed, no change