Issue 18831: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. Resolution: Revised Text: Actions taken: July 25, 2013: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Jul 2013 13:31:49 -0400 To: issues@omg.org, uml25-ftf@omg.org From: Juergen Boldt Subject: issue 18831 -- UML 2.5 FTF issue X-Virus-Scanned: amavisd-new at omg.org This is issue # 18831 From: "Rouquette, Nicolas F (313K)" Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] From: "Rouquette, Nicolas F (313K)" To: "uml25-ftf@omg.org" Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAIAAEQYAgAD/+ICAAAQ+AIAAFTcA//+USoCAAHragP//ja6AgACMkgCAACgggP//k6KAAA8bBQAABaBZAA== Date: Fri, 26 Jul 2013 04:20:13 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus usseful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring innter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . ssome of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivabble computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably th that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14MLTC104.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -10 X-BigFish: VS-10(z21cRzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: "Rouquette, Nicolas F (313K)" , "uml25-ftf@omg.org" Subject: RE: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYAgAEAuICAAAQ+AIAACA8ggAAWzwCAAARP4IAABDYAgAAP+dCAAC9fgIAACP4AgAADfACAAKJfgIAAfc5w Date: Fri, 26 Jul 2013 12:01:46 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org Nicolas I totally disagree with your proposed resolution for 18830. The idea of introducing a new primitive type and defining it in terms of OWL falls squarely into the category of an enhancement to the metamodel and is clearly out of scope for UML 2.5. We should defer this issue. Your resolution to 18831 is incomplete. I agree that a table of MOF tags in Annex E is a good idea, but it needs to be complete and needs to have some words describing what it means. There is no need for any separate issue. Thanks -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 05:20 To: uml25-ftf@omg.org Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementationn reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackerrmann numbers . which will not fit into the memory of anny conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably thathat includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 From: "Rouquette, Nicolas F (313K)" To: Steve Cook , "uml25-ftf@omg.org" Subject: Re: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAIAAEQYAgAD/+ICAAAQ+AIAAFTcA//+USoCAAHragP//ja6AgACMkgCAACgggP//k6KAAA8bBQAABaBZAAAeyh4AAADKqAA= Date: Fri, 26 Jul 2013 19:24:29 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Steve, For 18830, I will change the mapping of Real to xsd:string. For 18831, I'll complete the table for Annex E to cover the other PrimitiveTypes and explain the table. - Nicolas. From: Steve Cook Date: Friday, July 26, 2013 5:01 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: RE: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I totally disagree with your proposed resolution for 18830. The idea of introducing a new primitive type and defining it in terms of OWL falls squarely into the category of an enhancement to the metamodel and is clearly out of scope for UML 2.5. We should defer this issue. Your resolution to 18831 is incomplete. I agree that a table of MOF tags in Annex E is a good idea, but it needs to be complete and needs to have some words describing what it means. There is no need for any separate issue. Thanks -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 05:20 To: uml25-ftf@omg.org Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.aand is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, suchh as large Ackermann numbers . which will not fit into tthe memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). argarguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: 1 X-BigFish: VS1(z54e0izzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) From: Steve Cook To: "Rouquette, Nicolas F (313K)" , "uml25-ftf@omg.org" Subject: 18831 Thread-Topic: 18831 Thread-Index: Ac6NFRZ7Ygb8Ugu1R+aeXs94+4BKmw== Date: Tue, 30 Jul 2013 13:13:56 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org Nicolas You have: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20120801/UnlimitedNatural#unlimitedNatural I believe this should read: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20131001/UnlimitedNatural#unlimitedNatural And the version number in the schema should similarly be 20131001. However there is a deeper concern. I was wondering if the URL ought to contain the file extension, so I referred to the XMI spec. And the XMI spec says that the schemaType tag should refer to .The name of a datatype defined in the XML Schema Datatype specification.. This doesn.t appear to include the possibility of a locally-defined schema. So I am wondering if we are in practice limited to string. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 20:24 To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, For 18830, I will change the mapping of Real to xsd:string. For 18831, I'll complete the table for Annex E to cover the other PrimitiveTypes and explain the table. - Nicolas. From: Steve Cook Date: Friday, July 26, 2013 5:01 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: RE: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I totally disagree with your proposed resolution for 18830. The idea of introducing a new primitive type and defining it in terms of OWL falls squarely into the category of an enhancement to the metamodel and is clearly out of scope for UML 2.5. We should defer this issue. Your resolution to 18831 is incomplete. I agree that a table of MOF tags in Annex E is a good idea, but it needs to be complete and needs to have some words describing what it means. There is no need for any separate issue. Thanks -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 05:20 To: uml25-ftf@omg.org Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this.> -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-impplementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implemeentation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of whhich can be named, such as large Ackermann numbers . whiich will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity.< An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 From: "Rouquette, Nicolas F (313K)" To: Steve Cook , "uml25-ftf@omg.org" Subject: Re: 18831 Thread-Topic: 18831 Thread-Index: Ac6NFRZ7Ygb8Ugu1R+aeXs94+4BKmwAICywA Date: Tue, 30 Jul 2013 14:58:38 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Steve, I'll update 18831 with the UML 2.5 URIs after the telecon. Your deeper concern is justified. I believe there are two issues with the description of 'schemaType': The name of a datatype defined in the XML Schema Datatype specification. it isn't the name but the URI of a datatype. That is, instead of schemaType="integer", we instead say schemaType="http://www.w3.org/2001/XMLSchema#integer" Limiting the datatypes to those defined in the XML Schema Datatype spec means limiting to the "builtin" datatypes. This is contradictory to the intent of the XML Schema Datatype spec which enables defining a custom datatype from scratch or by restriction from a builtin datatype. Nicolas. From: Steve Cook Date: Tuesday, July 30, 2013 6:13 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: 18831 Nicolas You have: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20120801/UnlimitedNatural#unlimitedNatural I believe this should read: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20131001/UnlimitedNatural#unlimitedNatural And the version number in the schema should similarly be 20131001. However there is a deeper concern. I was wondering if the URL ought to contain the file extension, so I referred to the XMI spec. And the XMI spec says that the schemaType tag should refer to .The name of a datatype defined in the XML Schema Datatype specification.. This doesn.t appear to include the possibility of a locally-defined schema. So I am wondering if we are in practice limited to string. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 20:24 To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, For 18830, I will change the mapping of Real to xsd:string. For 18831, I'll complete the table for Annex E to cover the other PrimitiveTypes and explain the table. - Nicolas. From: Steve Cook Date: Friday, July 26, 2013 5:01 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: RE: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I totally disagree with your proposed resolution for 18830. The idea of introducing a new primitive type and defining it in terms of OWL falls squarely into the category of an enhancement to the metamodel and is clearly out of scope for UML 2.5. We should defer this issue. Your resolution to 18831 is incomplete. I agree that a table of MOF tags in Annex E is a good idea, but it needs to be complete and needs to have some words describing what it means. There is no need for any separate issue. Thanks -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 05:20 To: uml25-ftf@omg.org Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this.< -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementatioon reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-impplementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . wwhich will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (..-2, -1, 0, 1, 2.). arguably that incluudes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 Subject: RE: 18831 Date: Tue, 30 Jul 2013 08:08:49 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 18831 Thread-Index: Ac6NFRZ7Ygb8Ugu1R+aeXs94+4BKmwAICywAAABFoYA= From: "Pete Rivett" To: "Rouquette, Nicolas F (313K)" , "Steve Cook" , X-Virus-Scanned: amavisd-new at omg.org Ø This is contradictory to the intent of the XML Schema Datatype spec which enables defining a custom datatype from scratch or by restriction from a builtin datatype. But not to the intent of the XMI spec - which is what matters here! In that way it.s equivalent to OWL which only allows a fixed set of XSD-defined datatypes (an even smaller set). So I agree with Steve that we.re limited to string. Pete From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 30, 2013 7:59 AM To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18831 Steve, I'll update 18831 with the UML 2.5 URIs after the telecon. Your deeper concern is justified. I believe there are two issues with the description of 'schemaType': The name of a datatype defined in the XML Schema Datatype specification. it isn't the name but the URI of a datatype. That is, instead of schemaType="integer", we instead say schemaType="http://www.w3.org/2001/XMLSchema#integer" Limiting the datatypes to those defined in the XML Schema Datatype spec means limiting to the "builtin" datatypes. This is contradictory to the intent of the XML Schema Datatype spec which enables defining a custom datatype from scratch or by restriction from a builtin datatype. Nicolas. From: Steve Cook Date: Tuesday, July 30, 2013 6:13 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: 18831 Nicolas You have: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20120801/UnlimitedNatural#unlimitedNatural I believe this should read: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20131001/UnlimitedNatural#unlimitedNatural And the version number in the schema should similarly be 20131001. However there is a deeper concern. I was wondering if the URL ought to contain the file extension, so I referred to the XMI spec. And the XMI spec says that the schemaType tag should refer to .The name of a datatype defined in the XML Schema Datatype specification.. This doesn.t appear to include the possibility of a locally-defined schema. So I am wondering if we are in practice limited to string. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 20:24 To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, For 18830, I will change the mapping of Real to xsd:string. For 18831, I'll complete the table for Annex E to cover the other PrimitiveTypes and explain the table. - Nicolas. From: Steve Cook Date: Friday, July 26, 2013 5:01 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: RE: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I totally disagree with your proposed resolution for 18830. The idea of introducing a new primitive type and defining it in terms of OWL falls squarely into the category of an enhancement to the metamodel and is clearly out of scope for UML 2.5. We should defer this issue. Your resolution to 18831 is incomplete. I agree that a table of MOF tags in Annex E is a good idea, but it needs to be complete and needs to have some words describing what it means. There is no need for any separate issue. Thanks -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 05:20 To: uml25-ftf@omg.org Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for iinsuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as larrge Ackermann numbers . which will not fit into the memoory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably thathat includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 From: "Rouquette, Nicolas F (313K)" To: Pete Rivett , Steve Cook , "uml25-ftf@omg.org" Subject: Re: 18831 Thread-Topic: 18831 Thread-Index: Ac6NFRZ7Ygb8Ugu1R+aeXs94+4BKmwAICywAAABFoYAAL0augA== Date: Wed, 31 Jul 2013 13:40:05 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Pete, See below. From: Pete Adaptive Date: Tuesday, July 30, 2013 8:08 AM To: Nicolas Rouquette , Steve Cook , "uml25-ftf@omg.org" Subject: RE: 18831 Ø This is contradictory to the intent of the XML Schema Datatype spec which enables defining a custom datatype from scratch or by restriction from a builtin datatype. But not to the intent of the XMI spec - which is what matters here! NFR> Then the intent of the XMI spec is wrong. In that way it.s equivalent to OWL which only allows a fixed set of XSD-defined datatypes (an even smaller set). NFR> No .. OWL specifies a minimum "datatype map" that implementations must support. It is possible to use custom datatype definitions with OWL and RDF. See: http://www.w3.org/TR/2006/NOTE-swbp-xsch-datatypes-20060314/ So I agree with Steve that we.re limited to string. NFR> UnlimitedNatural is a good example that the intent of the XMI spec is counter-productive. What good does it do for UML when we say UnlimitedNatural maps to xsd:string? Is any string a legal UnlimitedNatural? Obviously no. XML Schema provides several ways to say precisely what the UML spec intends an UnlimitedNatural to be. I had proposed a unon-based approach because it's an example that's the XML Schema DataType spec already discusses: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#union-datatypes There are several examples in the the W3 note about using custom datatypes with OWL and RDF: http://www.w3.org/TR/2006/NOTE-swbp-xsch-datatypes-20060314/ Even the OWL2 specification shows how to specify custom datatype definitions using the OWL2 vocabulary equivalent of XML Schema Datatype facet restrictions: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Datatype_Restrictions Is this enough to convince you that there's a legitimate issue for XMI to fix this overly restrictive definition of schemaType? - Nicolas. Pete From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 30, 2013 7:59 AM To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18831 Steve, I'll update 18831 with the UML 2.5 URIs after the telecon. Your deeper concern is justified. I believe there are two issues with the description of 'schemaType': The name of a datatype defined in the XML Schema Datatype specification. it isn't the name but the URI of a datatype. That is, instead of schemaType="integer", we instead say schemaType="http://www.w3.org/2001/XMLSchema#integer" Limiting the datatypes to those defined in the XML Schema Datatype spec means limiting to the "builtin" datatypes. This is contradictory to the intent of the XML Schema Datatype spec which enables defining a custom datatype from scratch or by restriction from a builtin datatype. Nicolas. From: Steve Cook Date: Tuesday, July 30, 2013 6:13 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: 18831 Nicolas You have: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20120801/UnlimitedNatural#unlimitedNatural I believe this should read: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20131001/UnlimitedNatural#unlimitedNatural And the version number in the schema should similarly be 20131001. However there is a deeper concern. I was wondering if the URL ought to contain the file extension, so I referred to the XMI spec. And the XMI spec says that the schemaType tag should refer to .The name of a datatype defined in the XML Schema Datatype specification.. This doesn.t appear to include the possibility of a locally-defined schema. So I am wondering if we are in practice limited to string. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 20:24 To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, For 18830, I will change the mapping of Real to xsd:string. For 18831, I'll complete the table for Annex E to cover the other PrimitiveTypes and explain the table. - Nicolas. From: Steve Cook Date: Friday, July 26, 2013 5:01 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: RE: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I totally disagree with your proposed resolution for 18830. The idea of introducing a new primitive type and defining it in terms of OWL falls squarely into the category of an enhancement to the metamodel and is clearly out of scope for UML 2.5. We should defer this issue. Your resolution to 18831 is incomplete. I agree that a table of MOF tags in Annex E is a good idea, but it needs to be complete and needs to have some words describing what it means. There is no need for any separate issue. Thanks -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 05:20 To: uml25-ftf@omg.org Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thhus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-impplementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . somee of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that at includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 Subject: RE: 18831 Date: Wed, 31 Jul 2013 07:09:35 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 18831 Thread-Index: Ac6NFRZ7Ygb8Ugu1R+aeXs94+4BKmwAICywAAABFoYAAL0augAAAe1og From: "Pete Rivett" To: "Rouquette, Nicolas F (313K)" , "Steve Cook" , X-Virus-Scanned: amavisd-new at omg.org Nicolas, Thanks for the education on OWL. However it does not affect my core point. The intent of the XMI spec is to allow simple and predictable tool interchange, not to provide perfect validation of all XMI documents using XML technology alone. Which would still not be vaguely possible even if we were to adopt your proposal for UnlimitedNatural. Which would also place an undue burden on tools to support processing of arbitrary XML types when all we need is a very simple .*. . that most tools alreaddy have a hardcoded exception for. As everyone on this list is aware (and as per the approved resolution of 16582) we do not even see any value in generating an XML Schema at all for UML. If you think there really is a case for forcing tools to support parsing of arbitrary XML datatype definitions then feel free to raise an issue on XMI; but be aware that we are well beyond the comment deadline and unlikely to be resolved in the UML 2.5 RTF timescale. Pete From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, July 31, 2013 6:40 AM To: Pete Rivett; Steve Cook; uml25-ftf@omg.org Subject: Re: 18831 Pete, See below. From: Pete Adaptive Date: Tuesday, July 30, 2013 8:08 AM To: Nicolas Rouquette , Steve Cook , "uml25-ftf@omg.org" Subject: RE: 18831 Ø This is contradictory to the intent of the XML Schema Datatype spec which enables defining a custom datatype from scratch or by restriction from a builtin datatype. But not to the intent of the XMI spec - which is what matters here! NFR> Then the intent of the XMI spec is wrong. In that way it.s equivalent to OWL which only allows a fixed set of XSD-defined datatypes (an even smaller set). NFR> No . OWL specifies a minimum "datatype map" thhat implementations must support. It is possible to use custom datatype definitions with OWL and RDF. See: http://www.w3.org/TR/2006/NOTE-swbp-xsch-datatypes-20060314/ So I agree with Steve that we.re limited to string. NFR> UnlimitedNatural is a good example that the intent of the XMI spec is counter-productive. What good does it do for UML when we say UnlimitedNatural maps to xsd:string? Is any string a legal UnlimitedNatural? Obviously no. XML Schema provides several ways to say precisely what the UML spec intends an UnlimitedNatural to be. I had proposed a unon-based approach because it's an example that's the XML Schema DataType spec already discusses: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#union-datatypes There are several examples in the the W3 note about using custom datatypes with OWL and RDF: http://www.w3.org/TR/2006/NOTE-swbp-xsch-datatypes-20060314/ Even the OWL2 specification shows how to specify custom datatype definitions using the OWL2 vocabulary equivalent of XML Schema Datatype facet restrictions: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Datatype_Restrictions Is this enough to convince you that there's a legitimate issue for XMI to fix this overly restrictive definition of schemaType? - Nicolas. Pete From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 30, 2013 7:59 AM To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18831 Steve, I'll update 18831 with the UML 2.5 URIs after the telecon. Your deeper concern is justified. I believe there are two issues with the description of 'schemaType': The name of a datatype defined in the XML Schema Datatype specification. it isn't the name but the URI of a datatype. That is, instead of schemaType="integer", we instead say schemaType="http://www.w3.org/2001/XMLSchema#integer" Limiting the datatypes to those defined in the XML Schema Datatype spec means limiting to the "builtin" datatypes. This is contradictory to the intent of the XML Schema Datatype spec which enables defining a custom datatype from scratch or by restriction from a builtin datatype. Nicolas. From: Steve Cook Date: Tuesday, July 30, 2013 6:13 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: 18831 Nicolas You have: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20120801/UnlimitedNatural#unlimitedNatural I believe this should read: For PrimitiveTypes::UnlimitedNatural, tag .org.omg.xmi.schemaType. set to http://www.omg.org/spec/UML/20131001/UnlimitedNatural#unlimitedNatural And the version number in the schema should similarly be 20131001. However there is a deeper concern. I was wondering if the URL ought to contain the file extension, so I referred to the XMI spec. And the XMI spec says that the schemaType tag should refer to .The name of a datatype defined in the XML Schema Datatype specification.. This doesn.t appear to include the possibility of a locally-defined schema. So I am wondering if we are in practice limited to string. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 20:24 To: Steve Cook; uml25-ftf@omg.org Subject: Re: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, For 18830, I will change the mapping of Real to xsd:string. For 18831, I'll complete the table for Annex E to cover the other PrimitiveTypes and explain the table. - Nicolas. From: Steve Cook Date: Friday, July 26, 2013 5:01 AM To: Nicolas Rouquette , "uml25-ftf@omg.org" Subject: RE: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I totally disagree with your proposed resolution for 18830. The idea of introducing a new primitive type and defining it in terms of OWL falls squarely into the category of an enhancement to the metamodel and is clearly out of scope for UML 2.5. We should defer this issue. Your resolution to 18831 is incomplete. I agree that a table of MOF tags in Annex E is a good idea, but it needs to be complete and needs to have some words describing what it means. There is no need for any separate issue. Thanks -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 26 July 2013 05:20 To: uml25-ftf@omg.org Subject: 18830 and 18831 -- Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi, I have checked in resolutions for 18830 and 18831. I welcome any and all feedback; I hope we can constructively fix these things. I noticed that Annex E lacks a table summarizing the mofext:Tags we have in the XMI. Should I raise a separate issue to add such a table to show the mapping for the other primitive types? - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 11:39 AM To: Nicolas Rouquette , Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this.> -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible..and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-impleementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such aas large Ackermann numbers . which will not fit into thee memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that incincludes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /The standard type Real represents the mathematical concept of real. Note that UnlimitedNatural is a subclass of Integer and that Integer is a subclass of Real, so for each parameter of type Real, you can use an unlimited natural or an integer as the actual parameter./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zz9371I15bfKc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: "Rouquette, Nicolas F (313K)" , "uml25-ftf@omg.org" Subject: RE: Report on today's call Thread-Topic: Report on today's call Thread-Index: Ac6NPsB/YmEGgf4ORvG5Sjs3p6REjQAqF/YAAAGX2NA= Date: Wed, 31 Jul 2013 13:01:42 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org Nicolas, I have made some changes to what you checked in. 18831: changed the phrasing of the .note. . notes are not normative and this is normative. 17160: improved grammar; deleted a phrase that referred to the instance notation; changed all references in the XMI to PrimitiveTypes to be of the form http://www.omg.org/spec/UML/YYYYMMnn/PrimitiveTypes.xmi#Integer; removed an Eclipse xmlns; used ISO phrasing .shall. instead of .must.. You may want to check what I have done. I have kept change tracking on. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 31 July 2013 13:12 To: Steve Cook; uml25-ftf@omg.org Subject: Re: Report on today's call The updates for 18831 and 17160 are committed. - Nicolas. From: Steve Cook Date: Tuesday, July 30, 2013 9:28 AM To: "uml25-ftf@omg.org" Subject: Report on today's call Attending: Axel, Conrad, J D, Manfred, Nicolas, Bran, Pete, Ed, Steve Issue 17160. We discussed this extensively, especially the proposed notation for the application of profiles containing classes and associations. Finally we decided that this notation is a bridge too far for this FTF. It could be a very useful notation, and could also be seen as a special case of a general capability for creating diagrams of metamodel instances. In the meantime Nicolas will remove the notation aspects of the resolution. Issue 18831. We decided that UnlimitedNatural will map to xs:string, and Annex E should specify that unlimited serializes as .*.. Same time next week. Thanks -- Steve