Issue 6157: Property string undefined (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: The BNF for property-string is missing in Property and Operation. Eg, how are the properties delimited (a comma?)? How are property values shown (property-name property-value)? Resolution: see above Revised Text: Actions taken: August 30, 2003: received issue March 8, 2005: closed issue Discussion: This is in part a duplication of the problem reported in issue 7135, that the syntax for property strings is not given in a correct and consistent BNF. It is a shared superstructure/infrastructure issue. Section 7.10.1 Operation lacking proper BNF has been corrected with Issue 7135 This leaves us with the issue wrt Property. We propose a resolution that re-writes the text and syntax regarding propertystrings for Properties. The syntax as it is given in the FAS for both Infra and Super is defective, not only because it does not use BNF, but because it confuses the property-string, which includes the curly braces and delimiting commas, with the property expressions, which themselves are not always terminal literals, as they include such as 'redefines' <property-name> If the definition as it stands now in the FAS were taken literally, we would have a curly braces nested inside curly braces, because property strings are defined as if they were a composition of property strings! In addition, we a) correct an error in respect to the name 'redefines' which is mistakenly given as 'redefined' on page 83; // Note this next, b and c, is the part that may be going beyond what is desirable here: b) correct redundancy and omissions in property-string names for association ends, 'ordered' , 'bag' and 'sequence' a correction which brings the properties of association end collections in line with the properties of Collections. c) in cleaning up the syntax under Notation on page 83, we must move the semantics that are now mixed in with the syntax, back to page 81 in the semantics section. Discussion of (b): The property expression names for are defective in respect to definition and naming of bag, ordered, and sequence. For example, the current text says: "If the end is marked as unique, this collection is a set. This is at the very least misleading, in that a sequenced collection is not called a set, and an end marked as unique may also be marked in the property string for the end, as ordered. These 3 names for use as property expressions are intended to describe the collection denoted by an association end in respect of whether that collection is permits or prevents duplicates among the members of the collection, and whether the members are mapped to ordinal numbers to indicate a sequence. These two features of a collection are orthogonal, so that it is possible for there to be collections which allow duplicates, and are ordered, that prevent dupllicates, and are ordered, that allow duplicates and are not ordered, and that prevent duplicates and are not ordered. The defective set of three - ordered, sequence, bag - also leaves out one possibility. By making the property expressions 'ordered' and 'distinct' orthogonal, it is redundant to have the property expression 'sequence' as defined now. A collection that permits the same element to appear more than once need not be a bag, it could be an array with the same element in many positions. A set, in the usual sense, is not the same as an ordered sequence of non-recurring values, so it is wrong to say, "If the end is marked as unique, this collection is a set". You also need to mark it as not ordered. To correct these problems replace the following sentences from the Superstructure and Infrastructure FAS: Old Text: Semantics section on p. 82 Superstructure, p. 113 Infra An end of one association may be marked as redefining an end of another … New Text: An end of one association may be marked to show it redefines an end of another… Old Text: mid page 93 under "Notation" for Property Superstructure Only See "Classifer (from Kernel, Dependencies, PowerTypes)" on page 61. See "Association (from Kernel)" on page 81. New Text: avoid hard-coded page numbers, replace with: See Classifier (from Kernel, Dependencies, PowerTypes). See Association (from Kernel). Old Text: bottom of 81 continuing to top of 82, Superstructure Only If the end is marked as ordered, this collection will be ordered, If the end is marked as unique, this collection is a set; otherwise it allows duplicate elements. New Text: replace with: If an end is marked as ordered, its collection is organized as a sequence. If an end is marked as unique, no duplicates are permitted within its collection. Examples of usage: to specify the collection as a set, do not mark it as ordered but do mark it as unique; to specify a bag, do not mark the end as ordered, and do not mark it as unique. Old Text: beginning bottom of 83 Super, midpage 114, Infra A property string may be placed near the association symbol, but far enough from any end to not be confused with a property string on an end. New Text: add a sentence, so the result is as follows: A property string may be placed near the association symbol, but far enough from any end to not be confused with a property string on an end. A property string is a comma-delimited list of property expressions enclosed in curly braces. A property expression is, in the simplest case, a name such as 'redefines' or 'subsets'. Old Text: under Notation on page 83 Superstructure and page 114 Infra. New Text: The BNF for property strings on association ends is: <property-string> ::= '{' <end-property> [ ',' <end-property> ]* '}' <end-property> ::= ( 'subsets' <property-name> | 'redefines' <end-name> ) where <property-name> and <end-name> are names of user-provided properties and association ends found in the model context. If an association end is navigable, attribute-properties defined for attributes are legal as end-properties in the property string for that association end. End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Property string undefined The BNF for property-string is missing in Property and Operation. Eg, how are the properties delimited (a comma?)? How are property values Subject: Issue 6157 Date: Tue, 20 Jul 2004 17:15:53 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue 6157 Thread-Index: AcRumSVvPbiPVFL/Q8+3v1ZIOlTV4gAHlFPg From: "Karl Frank" To: "Branislav Selic" Cc: , , X-OriginalArrivalTime: 21 Jul 2004 00:16:05.0001 (UTC) FILETIME=[E992F790:01C46EB7] Please take a look at this for Ballot 20. - Karl ForBallot20_Classes_6157.doc Top Priority FTF Issue on Classes Chapter OMG Issue No: 6157 1 OMG Issue No: 6157 Title: Property string undefined Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The BNF for property-string is missing in Property and Operation. Eg, how are the properties delimited (a comma?)? How are property values shown (property-name property-value)? Discussion: This is in part a duplication of the problem reported in issue 7135, that the syntax for property strings is not given in a correct and consistent BNF. Section 7.10.1 Operation lacking proper BNF has been corrected with Issue 7135 This leaves us with the issue wrt Property. We propose a resolution that re-writes the text and syntax regarding property-strings for association ends, under Properties. The syntax as it is given in the FAS is defective, not only because it does not use BNF, but because it confuses the property-string, which includes the curly braces and delimiting commas, with the property expressions, which themselves are not always terminal literals, as they include such as redefines In addition, we a) correct an error in respect to the name 'redefines' which is mistakenly given as 'redefined' on page 83; // Note this next, b and c, is the part that may be going beyond what is desirable here: b) correct redundancy and omissions in property-string names for association ends, 'ordered' , 'bag' and 'sequence' a correction which brings the properties of association end collections in line with the properties of Collections. c) in cleaning up the syntax under Notation on page 83, we must move the semantics that are now mixed in with the syntax, back to page 81 in the semantics section. Discussion of (b): The property names for are defective in respect to definition and naming of the properties bag, ordered, and sequence. For example, the current text says: "If the end is marked as unique, this collection is a set. This is at the very least misleading, in that a sequenced collection is not called a set, and an end marked as unique may also be marked as ordered. These 3 property names are intended to describe the collection denoted by an association end in respect of whether that collection is permits or prevents duplicates among the members of the collection, and whether the members are mapped to ordinal numbers to indicate a sequence. These two features of a collection are orthogonal, so that it is possible for there to be collections which allow duplicates, and are ordered, that prevent dupllicates, and are ordered, that allow duplicates and are not ordered, and that prevent duplicates and are not ordered. The defective set of three - ordered, sequence, bag - also leaves out one possibility. By making the properties 'ordered' and 'distinct' orthogonal, it is redundant to have the property 'sequence' as defined now. A collection that permits the same element to appear more than once need not be a bag, it could be an array with the same element in many positions. A set, in the usual sense, is not the same as an ordered sequence of non-recurring values, so it is wrong to say, "If the end is marked as unique, this collection is a set". You also need to mark it as not ordered. To correct these problems replace the following sentences from the FAS: Old Text: Semantics section on p. 82: An end of one association may be marked as redefining an end of another . New Text: An end of one association may be marked to show it redefines an end of another. Old Text: mid page 93 under "Notation" See "Classifer (from Kernel, Dependencies, PowerTypes)" on page 61. See "Association (from Kernel)" on page 81. New Text: replace with: See Classifier (from Kernel, Dependencies, PowerTypes). See Association (from Kernel). Old Text: bottom of 81 continuing to top of 82 If the end is marked as ordered, this collection will be ordered, If the end is marked as unique, this collection is a set; otherwise it allows duplicate elements. New Text: replace with: If an end is marked as ordered, its collection is organized as a sequence. If an end is marked as unique, no duplicates are permitted within its collection. Examples of usage: to specify the collection as a set, do not mark it as ordered but do mark it as unique; to specify a bag, do not mark the end as ordered, and do not mark it as unique. Old Text: beginning bottom of 83 A property string may be placed near the association symbol, but far enough from any end to not be confused with a property string on an end. New Text: A property string is a comma-delimited list of property expressions enclosed in curly braces. Such a string may be placed near the association symbol, but far enough from any end to not be confused with a property string on an end. Old Text: under Notation on page 83 New Text: The BNF for property strings on association ends is: ::= '{' [ ',' ]* '}' ::= ( 'subsets' | 'redefines' | 'union' | 'ordered ' | 'unique' ) where and are names of user-provided properties and association ends found in the model context. If an association end is navigable, property expressions defined for attributes are legal in the property string for that association end. Disposition: Resolved Two Top Priority FTF Issues on Classes for Ballot 20 OMG Issue No: 6157 1 OMG Issue No: 6184 4 OMG Issue No: 6157 Title: Property string undefined Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The BNF for property-string is missing in Property and Operation. Eg, how are the properties delimited (a comma?)? How are property values shown (property-name property-value)? Discussion: This is in part a duplication of the problem reported in issue 7135, that the syntax for property strings is not given in a correct and consistent BNF. It is a shared superstructure/infrastructure issue. Section 7.10.1 Operation lacking proper BNF has been corrected with Issue 7135 This leaves us with the issue wrt Property. We propose a resolution that re-writes the text and syntax regarding property-strings for Properties. The syntax as it is given in the FAS for both Infra and Super is defective, not only because it does not use BNF, but because it confuses the property-string, which includes the curly braces and delimiting commas, with the property expressions, which themselves are not always terminal literals, as they include such as 'redefines' If the definition as it stands now in the FAS were taken literally, we would have a curly braces nested inside curly braces, because property strings are defined as if they were a composition of property strings! In addition, we a) correct an error in respect to the name 'redefines' which is mistakenly given as 'redefined' on page 83; // Note this next, b and c, is the part that may be going beyond what is desirable here: b) correct redundancy and omissions in property-string names for association ends, 'ordered' , 'bag' and 'sequence' a correction which brings the properties of association end collections in line with the properties of Collections. c) in cleaning up the syntax under Notation on page 83, we must move the semantics that are now mixed in with the syntax, back to page 81 in the semantics section. Discussion of (b): The property expression names for are defective in respect to definition and naming of bag, ordered, and sequence. For example, the current text says: "If the end is marked as unique, this collection is a set. This is at the very least misleading, in that a sequenced collection is not called a set, and an end marked as unique may also be marked in the property string for the end, as ordered. These 3 names for use as property expressions are intended to describe the collection denoted by an association end in respect of whether that collection is permits or prevents duplicates among the members of the collection, and whether the members are mapped to ordinal numbers to indicate a sequence. These two features of a collection are orthogonal, so that it is possible for there to be collections which allow duplicates, and are ordered, that prevent dupllicates, and are ordered, that allow duplicates and are not ordered, and that prevent duplicates and are not ordered. The defective set of three - ordered, sequence, bag - also leaves out one possibility. By making the property expressions 'ordered' and 'distinct' orthogonal, it is redundant to have the property expression 'sequence' as defined now. A collection that permits the same element to appear more than once need not be a bag, it could be an array with the same element in many positions. A set, in the usual sense, is not the same as an ordered sequence of non-recurring values, so it is wrong to say, "If the end is marked as unique, this collection is a set". You also need to mark it as not ordered. To correct these problems replace the following sentences from the Superstructure and Infrastructure FAS: Old Text: Semantics section on p. 82 Superstructure, p. 113 Infra An end of one association may be marked as redefining an end of another . New Text: An end of one association may be marked to show it redefines an end of another. Old Text: mid page 93 under "Notation" for Property Superstructure Only See "Classifer (from Kernel, Dependencies, PowerTypes)" on page 61. See "Association (from Kernel)" on page 81. New Text: avoid hard-coded page numbers, replace with: See Classifier (from Kernel, Dependencies, PowerTypes). See Association (from Kernel). Old Text: bottom of 81 continuing to top of 82, Superstructure Only If the end is marked as ordered, this collection will be ordered, If the end is marked as unique, this collection is a set; otherwise it allows duplicate elements. New Text: replace with: If an end is marked as ordered, its collection is organized as a sequence. If an end is marked as unique, no duplicates are permitted within its collection. Examples of usage: to specify the collection as a set, do not mark it as ordered but do mark it as unique; to specify a bag, do not mark the end as ordered, and do not mark it as unique. Old Text: beginning bottom of 83 Super, midpage 114, Infra A property string may be placed near the association symbol, but far enough from any end to not be confused with a property string on an end. New Text: add a sentence, so the result is as follows: A property string may be placed near the association symbol, but far enough from any end to not be confused with a property string on an end. A property string is a comma-delimited list of property expressions enclosed in curly braces. A property expression is, in the simplest case, a name such as 'redefines' or 'subsets'. Old Text: under Notation on page 83 Superstructure and page 114 Infra. New Text: The BNF for property strings on association ends is: ::= '{' [ ',' ]* '}' ::= ( 'subsets' | 'redefines' | 'union' | 'ordered ' | 'unique' ) where and are names of user-provided properties and association ends found in the model context. If an association end is navigable, property expressions defined for attributes are legal in the property string for that association end. Disposition: Resolved Subject: Two Classes Issues for Ballot 20 Date: Wed, 21 Jul 2004 11:45:05 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Two Classes Issues for Ballot 20 Thread-Index: AcRumSVvPbiPVFL/Q8+3v1ZIOlTV4gAr/EoA From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 21 Jul 2004 18:45:19.0202 (UTC) FILETIME=[DEF81C20:01C46F52] For consistency with Bran's proposal for resolving issue I have revised the terminology in the attached, using as the counterpart to the in Bran's proposal. We seem to have discovered the same solution to the same problem but used different terms for the non-terminal constituents of a property string. New Text: The BNF for property strings on association ends is: ::= '{' [ ',' ]* '}' ::= ( 'subsets' | 'redefines' | 'union' | 'ordered ' | 'unique' ) where and are names of user-provided properties and association ends found in the model context. If an association end is navigable, attribute-properties defined for attributes are legal as end-properties in the property string for that association end. -------------------------------------------------------------------- Please see attached. These both overlap infra and super, but the proposed resolution to 6184 does not require any change to infra. 6157 fixes a hole in BNF regarding property-string. - Karl Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 20 Date: Fri, 23 Jul 2004 15:57:45 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 20. Conrad 6153 (Interactions view of state machines/activities) This is being addressed in 7319, where we are avoiding introducing an xor. 6157 (Property string undefined) I gather this is consistent with 7135? 7135 (adopt a single notation to specify text strings used in the notation) Will this be updated to allow constraints on attributes, parameters, etc, like the old property list? 7253 (UML Sequence diagram) This is actually an activity issue. My proposed resolution text would be: "The arrows in activity diagrams are flows, not messages, so cannot be asynchronous. For more explanation, see http://www.jot.fm/issues/issue_2004_07/column4." 7328 (enumerated type MessageSort) Seems like "asynchSignal" should be "signal". There aren't any To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 20 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 23 Jul 2004 16:33:07 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/23/2004 16:33:08, Serialize complete at 07/23/2004 16:33:08 Thanks, Conrad. My feedback below: > 6153 (Interactions view of state machines/activities) > > This is being addressed in 7319, where we are avoiding introducing > an xor. Fair enough. However, I will keep this in the ballot, just in case 7319 gets hung up (as it might). If and when that resolution is adopted, it is no problem to overwrite this resolution. > 6157 (Property string undefined) > > I gather this is consistent with 7135? Yes. Karl and I worked together on this. > 7135 (adopt a single notation to specify text strings used in the > notation) > > Will this be updated to allow constraints on attributes, parameters, > etc, like the old property list? Yes. > 7253 (UML Sequence diagram) > > This is actually an activity issue. My proposed resolution text > would be: > > "The arrows in activity diagrams are flows, not messages, so > cannot be asynchronous. For more explanation, see > http://www.jot.fm/issues/issue_2004_07/column4." OK. Replaced my resolution with yours but retained "closed, no change" disposition. > 7328 (enumerated type MessageSort) > > Seems like "asynchSignal" should be "signal". There aren't any > synchronous signals are there? True, but it is useful to include the "asynch" reminder. It is also consistent with the format of the other enumerations. Cheers...Bran Subject: RE: Ballot 20 -- please vote Date: Fri, 30 Jul 2004 13:49:44 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 20 -- please vote Thread-Index: AcRw/gu5mJUOa/uKQEepJYKAW/icLQFVrKZg From: "Pete Rivett" To: "Branislav Selic" , Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com Adaptive votes YES to all proposed resolutions (bar the withdrawn 7153), except 6157 and 7135 to which it votes NO, . Sorry I did not pick these up earlier but I think 7135 in particular should be withdrawn this time round - to a) establish whether it was intentional to withdraw a chunk of notation (which was not mentioned anywhere in the issue or discussion) and b) to fix up the numerous Super-only cross-references in the Infra replacement text. The problem with 6157 is the sentence "If an association end is navigable, attribute-properties defined for attributes are legal as end-properties in the property string for that association end." This reflects the old definition of navigable; even if corrected to refer to ownership it would be wrong since there is no reason to prevent the specification of properties such as {ordered} on ends which are owned by the Association itself. Another problem is that the section now referenced on attribute notation (Infra 11.3.3) does not actually say what the strings such as {bag} actually mean: the text deleted by this resolution, while somewhat redundant, does at least have an explanation. BTW what is the difference between {seq} and {ordered}? 7135 removes some significant notation in the guise of cleaning up the specification syntax. For example in Infra p120-121 it proposes changing: . property-string indicates property values that apply to the attribute. The property string is optional (the braces are omitted if no properties are specified). The following property strings can be applied to an attribute: {readOnly}, {union}, {subsets }, {redefines }, {ordered}, {bag}, {seq} or {sequence}, and {composite} with the BNF: o indicates a property that applies to the attribute (refer to the Semantics subsection of Property on page 91 for their interpretation and rules) ::= .readOnly. | .union. | .subsets. | .redefines. So in the process this seems to have wiped out {bag}, {seq} or {sequence} and {composite}. Not only for attributes but for association ends (due to 6157 referred to above). Another problem is that this is an Infra resolution and the semantics of Property are not on p91 of Infra (this is true of many other cross-references in the resolution which include mentions of Kernel). Nor, in Infra, do the semantics define {bag} etc (assuming it was not intentional to wipe it out as an option). I'm not particularly keen on {bag} and {seq} but would like the dropping of notation to be a lot more explicit and deliberate. Another problem is that the resolution does not add the description of the BNF notation (first item under the changes to Super) to Infra. And the first change under Infra has the type The real problem with the issue though is the cross-references in the Infra section. Note: there is a typo in the first sentence of the Discussion of 6981 which says: "The notion of State in a sequence diagram does not necessarily map to the notion of State in sequence diagrams (although it might). " I presume one of the 'sequence diagrams' should be 'interaction diagrams' and suggest this be made as an editorial change to avoid confusing subsequent reviewers. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, July 23, 2004 10:34 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 20 -- please vote Attached, please find Ballot 20 with 25 proposed resolutions in it. The voting starts tonigth at 6 pm EDT and finishes at 6 pm EDT on Friday, July 30. Bran To: "Pete Rivett" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Ballot 20 -- please vote X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 30 Jul 2004 14:12:16 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/30/2004 14:12:19, Serialize complete at 07/30/2004 14:12:19 Thanks, pete for the feedback. Comments below: > Adaptive votes YES to all proposed resolutions (bar the withdrawn > 7153), except 6157 and 7135 to which it votes NO, . > > Sorry I did not pick these up earlier but I think 7135 in particular > should be withdrawn this time round - to a) establish whether it was > intentional to withdraw a chunk of notation (which was not mentioned > anywhere in the issue or discussion) and There was no intentional removal of any syntax, although in some cases it was completely unclear what the original intent was. In particular, there were examples of blind copy paste from one place to another (e.g., from association end to attribute). The things that you have spotted were probably those cases. > b) to fix up the numerous > Super-only cross-references in the Infra replacement text. The page numbers of cross-references are automatically computed by FrameMaker. The page numbers in the text will, of course, adjust as soon as the appropriate cross-reference is inserted. The numbers that are in there don't mean a thing (I thought people were clear on this -- I guess I should have explained it, but it's been that way for the last 19 ballots). > The problem with 6157 is the sentence "If an association end is > navigable, attribute-properties defined for attributes are legal as > end-properties in the property string for that association end." > This reflects the old definition of navigable; even if corrected to > refer to ownership it would be wrong since there is no reason to > prevent the specification of properties such as {ordered} on ends > which are owned by the Association itself. > Another problem is that the section now referenced on attribute > notation (Infra 11.3.3) does not actually say what the strings such > as {bag} actually mean: the text deleted by this resolution, while > somewhat redundant, does at least have an explanation. > BTW what is the difference between {seq} and {ordered}? Karl actually has recently provided a resolution that provides explanations for some of these things. Also, there are additional explanations on page 92 of the Super FAS. You will also find the answer to the question at the end on this page. > 7135 removes some significant notation in the guise of cleaning up Can't say that I care for the word "guise" -- there was no attempt to "guise" anything. > the specification syntax. For example in Infra p120-121 it proposes changing: > . property-stringg indicates property values that apply to the > attribute. The property string is optional (the braces are omitted > if no properties are specified). The following property strings can > be applied to an attribute: {readOnly}, {union}, {subsets name>}, {redefines > }, {ordered}, {bag}, {seq} or {sequence}, and {composite} > > with the BNF: > o indicates a property that applies to the > attribute (refer to the Semantics subsection of Property on page 91 > for their interpretation and rules) > > ::= â..readOnlyâ.. | â..unionâ.. | â..subsetsâ.. | > â..redefinesâ.. This looks like eitehr an oversight or the result of some bad editing during resolution revision (I revised this part several times in an attempt to synchronize with what Karl was doing). I will include those back in. > So in the process this seems to have wiped out {bag}, {seq} or > {sequence} and {composite}. Not only for attributes but for > association ends (due to 6157 referred to above). > Another problem is that this is an Infra resolution and the > semantics of Property are not on p91 of Infra (this is true of many > other cross-references in the resolution which include mentions of > Kernel). As I said, the cross-references are irrelevant and will be automatically corrected. ... > > Note: there is a typo in the first sentence of the Discussion of > 6981 which says: "The notion of State in a sequence diagram does not > necessarily map to the notion of State in sequence diagrams > (although it might). " > I presume one of the 'sequence diagrams' should be 'interaction > diagrams' and suggest this be made as an editorial change to avoid > confusing subsequent reviewers. This has already been noted. Since it is possible that not all your points will be fixed during entry into the document, I suggest that people have a look at what is in there on Monday when I produce the new version of the spec and then raise issues to fix anything that is incomplete or broken. Bran shown (property-name property-value)?