Issue 19512: UML 2.5 Beta 2 XMI invalid (uml2-rtf) Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com) Nature: Uncategorized Issue Severity: Summary: The UML.xmi available from http://www.omg.org/spec/UML/20131001/UML.xmi, currently linked as UML 2.5 Beta 2, isn't valid. It contains duplicate ids for the package imports, so it isn't even valid XML let alone XMI. Resolution: Revised Text: Actions taken: July 7, 2014: received issue Discussion: End of Annotations:===== te: Mon, 07 Jul 2014 16:57:00 +0100 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: "uml2-rtf@omg.org" Subject: UML 2.5 Beta 2 XMI invalid X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Virus-Scanned: amavisd-new at omg.org Hi, The UML.xmi available from http://www.omg.org/spec/UML/20131001/UML.xmi, currently linked as UML 2.5 Beta 2, isn't valid. It contains duplicate ids for the package imports, so it isn't even valid XML let alone XMI. Cheers, Dave -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Tom Rutt To: "Manfred R. Koethe" , Andrew Watson CC: "Rouquette, Nicolas F (313D)" , "Ed Seidewitz" , Dave Hawkins , "uml2-rtf@omg.org" , Tom Rutt Date: Sat, 12 Jul 2014 11:08:24 -0700 Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: Ac+dNbYgHp/RXbrTT0SwdbEcinj91AAxo+Ld Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-07-12_02:2014-07-11,2014-07-12,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id s6CIB3P9022923 again we must not confuse the package URI which is like a namespace. We do not need to change the package URI for this fix. However, how does one distinguish the old broken file from the new fixed one if the filename iteself for the XMI does not have a new date segment? Someone my use the old file instead of the fixed one if we just replace the file in place. Tom ________________________________________ From: Manfred R. Koethe [koethe@88solutions.com] Sent: Friday, July 11, 2014 8:23 PM To: Andrew Watson Cc: Rouquette, Nicolas F (313D); Ed Seidewitz; Dave Hawkins; uml2-rtf@omg.org Subject: Re: UML 2.5 Beta 2 XMI invalid Andrew, I second Ed¡¯s statement. As co-chair of the UML 2.5 FTF I can confirm there were no votes conducted to change those identifiers away from what they have been in the Alpha / Beta-1 version. So what we here try to accomplish is to undo an error that had been introduced in the (complex) final production process of the XMI files. Unfortunately these errors stayed unnoticed until now. Correcting these errors is a rather cosmetic act, since these ids are not referenced anywhere. (I checked!) And end-users are not affected since they are supposed to use the UML package that has all these package imports already resolved. In summary, let¡¯s correct this and KEEP the version stamp as it is. This resolves this really editorial problem and has THE LEAST (NO?) tool impact. Changing the version stamp would to my knowledge at least impact MagicDraw 18, but probably others too - for no technical reason¡¦.. Thank you in advance, Manfred On Jul 11, 2014, at 08:36 , Ed Seidewitz > wrote: Andrew - The point is that the changes to be made now are to undo changes that were inadvertently made in a delivered artifact that were not authorized by the FTF. XMI aside, what is the usual policy for correcting something like that? ¡ª Ed On 7/11/14, 8:01 AM, "Andrew Watson" > wrote: Ed, You wrote: Well, I could see it as being editorial in the sense that this problem did not exist in the publicly released Beta 1 version of the XMI and the change in the Beta 2 version did not correspond to anything approved by the FTF. It seems to me that it is similar to the case of the editor of the Beta 2 specification accidentally deleting a line from the document that was clearly in both the Alpha and Beta 1 spec documents and should have been in the Beta 2 version without change. In the updated XMI I sent to Dave, the XMI IDs for the package exports were restored to exactly what they were in the Alpha and Beta 1 XMI documents. This is similar to an editor restoring the missing line in the above example ¨¢ the editor doesn1t even have to know what the missing line really means, just that the document doesn1t make grammatical sense without it. (Though, of course, in this case I do happen to know what the XMI meansS) If these changes are indeed implementing the documented motions passed by the RTF, and not making *any* changes not already voted by the RTF, then it is indeed unarguable that they're "editorial", and should be made. However, do be careful what you wish for. As a matter of practicality we have in the past been a bit liberal about allowing an RTF's XMI to be fixed up (usually by Pete) in the last few hours before the report gets its AB approval. Provided everyone agrees that the XMI file identified in the report's inventory is "right", we haven't always been too fussy about making sure that all the changes to it come from properly documented RTF motions. By all means use the letter of the process to allow this XMI to be reverted editorially, but for consistency, that means we should start insisting that all changes to all XMI files be completely documented in every RTF report. In the long run, is that better or worse than doing an Urgent Issue to change this file, which was implicitly signed off by the RTF and AB because it was listed in the inventory? And in any case, we still need to use a new version stamp in the new file's URL on the OMG specification site. Yours even-handedly, Andrew --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: Ed Seidewitz To: Tom Rutt CC: "Manfred R. Koethe" , Andrew Watson , "Rouquette, Nicolas F (313D)" , Dave Hawkins , "uml2-rtf@omg.org" Subject: Re: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmfxKmLaDNAfdWE6FagL1NnIQVpubDuSA///4/gCAAHGoAIABjhYA//+/1/E= Date: Sat, 12 Jul 2014 18:18:45 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailprotector-Decision: deliver X-Mailprotector-Original-Sender: ed-s@modeldriven.com X-Mailprotector-Original-Recipients: trutt@us.fujitsu.com, koethe@88solutions.com, andrew@omg.org, nicolas.f.rouquette@jpl.nasa.gov, dave.hawkins@oracle.com, uml2-rtf@omg.org X-Mailprotector-Redirect-To: ed-s@modeldriven.com X-Mailprotector-Connection: TLSv1|cas203.mailprotector.com|54.208.113.85|CAS203.mailprotector.local|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: clean X-Mailprotector-Score: 0 X-Mailprotector-IP-Analysis: 0, 54.208.113.85, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-7200-c X-Mailprotector-ID: 05ae3708-0d12-41bd-b95d-1fd56d89dc31 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id s6CIMN7t023290 I think it may be more likely that people will use the wrong file if we don't change it in place. If the namespace URI date segment is different than the file name URI, then one would need to use the former in the namespace declaration by the latter in any hrefs to UML metamodel elements. It is hard enough to get this right when everything matches, let alone when it is different. On the other hand, with the primitive types in a separate file that wouldn't change, the above problem would only be apparent for profiles or metamodeling. So maybe it isn't so bad. Ed Sent from my iPhone > On Jul 12, 2014, at 2:10 PM, "Tom Rutt" wrote: > > again we must not confuse the package URI which is like a namespace. > > We do not need to change the package URI for this fix. > > However, how does one distinguish the old broken file from the new fixed one if the filename > iteself for the XMI does not have a new date segment? > > Someone my use the old file instead of the fixed one if we just replace the file in place. > > Tom > ________________________________________ > From: Manfred R. Koethe [koethe@88solutions.com] > Sent: Friday, July 11, 2014 8:23 PM > To: Andrew Watson > Cc: Rouquette, Nicolas F (313D); Ed Seidewitz; Dave Hawkins; uml2-rtf@omg.org > Subject: Re: UML 2.5 Beta 2 XMI invalid > > Andrew, > > I second Ed¡¯s statement. As co-chair of the UML 2.5 FTF I can confirm there were > no votes conducted to change those identifiers away from what they have been in > the Alpha / Beta-1 version. So what we here try to accomplish is to undo an error > that had been introduced in the (complex) final production process of the XMI files. > > Unfortunately these errors stayed unnoticed until now. > > Correcting these errors is a rather cosmetic act, since these ids are not referenced > anywhere. (I checked!) And end-users are not affected since they are supposed to > use the UML package that has all these package imports already resolved. > > In summary, let¡¯s correct this and KEEP the version stamp as it is. This resolves > this really editorial problem and has THE LEAST (NO?) tool impact. Changing the > version stamp would to my knowledge at least impact MagicDraw 18, but probably > others too - for no technical reason¡¦.. > > Thank you in advance, > > Manfred > > > On Jul 11, 2014, at 08:36 , Ed Seidewitz > wrote: > > Andrew - > > The point is that the changes to be made now are to undo changes that were > inadvertently made in a delivered artifact that were not authorized by the > FTF. XMI aside, what is the usual policy for correcting something like > that? > > ¡ª Ed > > On 7/11/14, 8:01 AM, "Andrew Watson" > wrote: > > Ed, > > You wrote: > > Well, I could see it as being editorial in the sense that this problem > did > not exist in the publicly released Beta 1 version of the XMI and the > change in the Beta 2 version did not correspond to anything approved by > the FTF. It seems to me that it is similar to the case of the editor of > the Beta 2 specification accidentally deleting a line from the document > that was clearly in both the Alpha and Beta 1 spec documents and should > have been in the Beta 2 version without change. > > In the updated XMI I sent to Dave, the XMI IDs for the package exports > were restored to exactly what they were in the Alpha and Beta 1 XMI > documents. This is similar to an editor restoring the missing line in > the > above example ¨¢ the editor doesn1t even have to know what the missing > line > really means, just that the document doesn1t make grammatical sense > without it. (Though, of course, in this case I do happen to know what > the > XMI meansS) > > If these changes are indeed implementing the documented motions passed by > the RTF, and not making *any* changes not already voted by the RTF, then > it > is indeed unarguable that they're "editorial", and should be made. > > However, do be careful what you wish for. As a matter of practicality we > have in the past been a bit liberal about allowing an RTF's XMI to be > fixed > up (usually by Pete) in the last few hours before the report gets its AB > approval. Provided everyone agrees that the XMI file identified in the > report's inventory is "right", we haven't always been too fussy about > making sure that all the changes to it come from properly documented RTF > motions. > > By all means use the letter of the process to allow this XMI to be > reverted > editorially, but for consistency, that means we should start insisting > that > all changes to all XMI files be completely documented in every RTF report. > In the long run, is that better or worse than doing an Urgent Issue to > change this file, which was implicitly signed off by the RTF and AB > because > it was listed in the inventory? > > And in any case, we still need to use a new version stamp in the new > file's > URL on the OMG specification site. > > Yours even-handedly, > > Andrew > > > --------------------------------------------------------------- > Manfred R. Koethe 88solutions Corporation > tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 > mailto: koethe@88solutions.com > web: http://www.88solutions.com > --------(Model-Driven Modeling Solutions)-------- > > > > > > > From: Ed Seidewitz To: Tom Rutt CC: "Manfred R. Koethe" , Andrew Watson , "Rouquette, Nicolas F (313D)" , Dave Hawkins , "uml2-rtf@omg.org" Subject: Re: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmfxKmLaDNAfdWE6FagL1NnIQVpubDuSA///4/gCAAHGoAIABjhYA//+/1/GAAAEm2oAAHahf Date: Sat, 12 Jul 2014 20:09:00 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailprotector-Decision: deliver X-Mailprotector-Original-Sender: ed-s@modeldriven.com X-Mailprotector-Original-Recipients: trutt@us.fujitsu.com, koethe@88solutions.com, andrew@omg.org, nicolas.f.rouquette@jpl.nasa.gov, dave.hawkins@oracle.com, uml2-rtf@omg.org X-Mailprotector-Redirect-To: ed-s@modeldriven.com X-Mailprotector-Connection: TLSv1|ec2-54-208-239-9.compute-1.amazonaws.com|54.208.239.9|CAS202.mailprotector.local|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: clean X-Mailprotector-Score: 0 X-Mailprotector-IP-Analysis: 0, 54.208.239.9, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-8501-c X-Mailprotector-ID: b2d3ad3b-d0d6-4577-9f2b-f12fd729dc2c X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id s6CKAJ3H025684 In addition, note that the filename URLs (not the namespace URIs) are listed on the cover of the UML 2.5 and the files so referenced are explicitly included as a normative part specification as stated at the end of Clause 2 (indeed, in case of conflicts, the files take precedence). So, if we change a file URL, we would also need to update the cover of the spec doc -- which we seem to mean we would then really want it to be UML 2.5.1 (or just wait until UML 2.6...). Unless we also allow this as an editorial change when the formal doc is published. Ed Sent from my iPhone > On Jul 12, 2014, at 2:24 PM, "Ed Seidewitz" wrote: > > Presumably any new doc would get a new PTC number in any case. Could we let the PTC doc number change but leave the dated URL the same? > > Sent from my iPhone > >> On Jul 12, 2014, at 2:18 PM, "Ed Seidewitz" wrote: >> >> I think it may be more likely that people will use the wrong file if we don't change it in place. If the namespace URI date segment is different than the file name URI, then one would need to use the former in the namespace declaration by the latter in any hrefs to UML metamodel elements. It is hard enough to get this right when everything matches, let alone when it is different. >> >> On the other hand, with the primitive types in a separate file that wouldn't change, the above problem would only be apparent for profiles or metamodeling. So maybe it isn't so bad. >> >> Ed >> >> Sent from my iPhone >> >>> On Jul 12, 2014, at 2:10 PM, "Tom Rutt" wrote: >>> >>> again we must not confuse the package URI which is like a namespace. >>> >>> We do not need to change the package URI for this fix. >>> >>> However, how does one distinguish the old broken file from the new fixed one if the filename >>> iteself for the XMI does not have a new date segment? >>> >>> Someone my use the old file instead of the fixed one if we just replace the file in place. >>> >>> Tom >>> ________________________________________ >>> From: Manfred R. Koethe [koethe@88solutions.com] >>> Sent: Friday, July 11, 2014 8:23 PM >>> To: Andrew Watson >>> Cc: Rouquette, Nicolas F (313D); Ed Seidewitz; Dave Hawkins; uml2-rtf@omg.org >>> Subject: Re: UML 2.5 Beta 2 XMI invalid >>> >>> Andrew, >>> >>> I second Ed¡¯s statement. As co-chair of the UML 2.5 FTF I can confirm there were >>> no votes conducted to change those identifiers away from what they have been in >>> the Alpha / Beta-1 version. So what we here try to accomplish is to undo an error >>> that had been introduced in the (complex) final production process of the XMI files. >>> >>> Unfortunately these errors stayed unnoticed until now. >>> >>> Correcting these errors is a rather cosmetic act, since these ids are not referenced >>> anywhere. (I checked!) And end-users are not affected since they are supposed to >>> use the UML package that has all these package imports already resolved. >>> >>> In summary, let¡¯s correct this and KEEP the version stamp as it is. This resolves >>> this really editorial problem and has THE LEAST (NO?) tool impact. Changing the >>> version stamp would to my knowledge at least impact MagicDraw 18, but probably >>> others too - for no technical reason¡¦.. >>> >>> Thank you in advance, >>> >>> Manfred >>> >>> >>> On Jul 11, 2014, at 08:36 , Ed Seidewitz > wrote: >>> >>> Andrew - >>> >>> The point is that the changes to be made now are to undo changes that were >>> inadvertently made in a delivered artifact that were not authorized by the >>> FTF. XMI aside, what is the usual policy for correcting something like >>> that? >>> >>> ¡ª Ed >>> >>> On 7/11/14, 8:01 AM, "Andrew Watson" > wrote: >>> >>> Ed, >>> >>> You wrote: >>> >>> Well, I could see it as being editorial in the sense that this problem >>> did >>> not exist in the publicly released Beta 1 version of the XMI and the >>> change in the Beta 2 version did not correspond to anything approved by >>> the FTF. It seems to me that it is similar to the case of the editor of >>> the Beta 2 specification accidentally deleting a line from the document >>> that was clearly in both the Alpha and Beta 1 spec documents and should >>> have been in the Beta 2 version without change. >>> >>> In the updated XMI I sent to Dave, the XMI IDs for the package exports >>> were restored to exactly what they were in the Alpha and Beta 1 XMI >>> documents. This is similar to an editor restoring the missing line in >>> the >>> above example ¨¢ the editor doesn1t even have to know what the missing >>> line >>> really means, just that the document doesn1t make grammatical sense >>> without it. (Though, of course, in this case I do happen to know what >>> the >>> XMI meansS) >>> >>> If these changes are indeed implementing the documented motions passed by >>> the RTF, and not making *any* changes not already voted by the RTF, then >>> it >>> is indeed unarguable that they're "editorial", and should be made. >>> >>> However, do be careful what you wish for. As a matter of practicality we >>> have in the past been a bit liberal about allowing an RTF's XMI to be >>> fixed >>> up (usually by Pete) in the last few hours before the report gets its AB >>> approval. Provided everyone agrees that the XMI file identified in the >>> report's inventory is "right", we haven't always been too fussy about >>> making sure that all the changes to it come from properly documented RTF >>> motions. >>> >>> By all means use the letter of the process to allow this XMI to be >>> reverted >>> editorially, but for consistency, that means we should start insisting >>> that >>> all changes to all XMI files be completely documented in every RTF report. >>> In the long run, is that better or worse than doing an Urgent Issue to >>> change this file, which was implicitly signed off by the RTF and AB >>> because >>> it was listed in the inventory? >>> >>> And in any case, we still need to use a new version stamp in the new >>> file's >>> URL on the OMG specification site. >>> >>> Yours even-handedly, >>> >>> Andrew >>> >>> >>> --------------------------------------------------------------- >>> Manfred R. Koethe 88solutions Corporation >>> tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 >>> mailto: koethe@88solutions.com >>> web: http://www.88solutions.com >>> --------(Model-Driven Modeling Solutions)-------- >>> >>> >>> >>> >>> >>> >>> From: Ed Seidewitz To: Tom Rutt CC: "Manfred R. Koethe" , Andrew Watson , "Rouquette, Nicolas F (313D)" , Dave Hawkins , "uml2-rtf@omg.org" Subject: Re: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmfxKmLaDNAfdWE6FagL1NnIQVpubDuSA///4/gCAAHGoAIABjhYA//+/1/GAAAEm2g== Date: Sat, 12 Jul 2014 18:22:52 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailprotector-Decision: deliver X-Mailprotector-Original-Sender: ed-s@modeldriven.com X-Mailprotector-Original-Recipients: trutt@us.fujitsu.com, koethe@88solutions.com, andrew@omg.org, nicolas.f.rouquette@jpl.nasa.gov, dave.hawkins@oracle.com, uml2-rtf@omg.org X-Mailprotector-Redirect-To: ed-s@modeldriven.com X-Mailprotector-Connection: TLSv1|ec2-54-208-239-9.compute-1.amazonaws.com|54.208.239.9|CAS202.mailprotector.local|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: clean X-Mailprotector-Score: 0 X-Mailprotector-IP-Analysis: 0, 54.208.239.9, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-7631-c X-Mailprotector-ID: 1bbd6318-2b7f-44bd-b5ca-d85151c973bf X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id s6CIN36E023336 Presumably any new doc would get a new PTC number in any case. Could we let the PTC doc number change but leave the dated URL the same? Sent from my iPhone > On Jul 12, 2014, at 2:18 PM, "Ed Seidewitz" wrote: > > I think it may be more likely that people will use the wrong file if we don't change it in place. If the namespace URI date segment is different than the file name URI, then one would need to use the former in the namespace declaration by the latter in any hrefs to UML metamodel elements. It is hard enough to get this right when everything matches, let alone when it is different. > > On the other hand, with the primitive types in a separate file that wouldn't change, the above problem would only be apparent for profiles or metamodeling. So maybe it isn't so bad. > > Ed > > Sent from my iPhone > >> On Jul 12, 2014, at 2:10 PM, "Tom Rutt" wrote: >> >> again we must not confuse the package URI which is like a namespace. >> >> We do not need to change the package URI for this fix. >> >> However, how does one distinguish the old broken file from the new fixed one if the filename >> iteself for the XMI does not have a new date segment? >> >> Someone my use the old file instead of the fixed one if we just replace the file in place. >> >> Tom >> ________________________________________ >> From: Manfred R. Koethe [koethe@88solutions.com] >> Sent: Friday, July 11, 2014 8:23 PM >> To: Andrew Watson >> Cc: Rouquette, Nicolas F (313D); Ed Seidewitz; Dave Hawkins; uml2-rtf@omg.org >> Subject: Re: UML 2.5 Beta 2 XMI invalid >> >> Andrew, >> >> I second Ed¡¯s statement. As co-chair of the UML 2.5 FTF I can confirm there were >> no votes conducted to change those identifiers away from what they have been in >> the Alpha / Beta-1 version. So what we here try to accomplish is to undo an error >> that had been introduced in the (complex) final production process of the XMI files. >> >> Unfortunately these errors stayed unnoticed until now. >> >> Correcting these errors is a rather cosmetic act, since these ids are not referenced >> anywhere. (I checked!) And end-users are not affected since they are supposed to >> use the UML package that has all these package imports already resolved. >> >> In summary, let¡¯s correct this and KEEP the version stamp as it is. This resolves >> this really editorial problem and has THE LEAST (NO?) tool impact. Changing the >> version stamp would to my knowledge at least impact MagicDraw 18, but probably >> others too - for no technical reason¡¦.. >> >> Thank you in advance, >> >> Manfred >> >> >> On Jul 11, 2014, at 08:36 , Ed Seidewitz > wrote: >> >> Andrew - >> >> The point is that the changes to be made now are to undo changes that were >> inadvertently made in a delivered artifact that were not authorized by the >> FTF. XMI aside, what is the usual policy for correcting something like >> that? >> >> ¡ª Ed >> >> On 7/11/14, 8:01 AM, "Andrew Watson" > wrote: >> >> Ed, >> >> You wrote: >> >> Well, I could see it as being editorial in the sense that this problem >> did >> not exist in the publicly released Beta 1 version of the XMI and the >> change in the Beta 2 version did not correspond to anything approved by >> the FTF. It seems to me that it is similar to the case of the editor of >> the Beta 2 specification accidentally deleting a line from the document >> that was clearly in both the Alpha and Beta 1 spec documents and should >> have been in the Beta 2 version without change. >> >> In the updated XMI I sent to Dave, the XMI IDs for the package exports >> were restored to exactly what they were in the Alpha and Beta 1 XMI >> documents. This is similar to an editor restoring the missing line in >> the >> above example ¨¢ the editor doesn1t even have to know what the missing >> line >> really means, just that the document doesn1t make grammatical sense >> without it. (Though, of course, in this case I do happen to know what >> the >> XMI meansS) >> >> If these changes are indeed implementing the documented motions passed by >> the RTF, and not making *any* changes not already voted by the RTF, then >> it >> is indeed unarguable that they're "editorial", and should be made. >> >> However, do be careful what you wish for. As a matter of practicality we >> have in the past been a bit liberal about allowing an RTF's XMI to be >> fixed >> up (usually by Pete) in the last few hours before the report gets its AB >> approval. Provided everyone agrees that the XMI file identified in the >> report's inventory is "right", we haven't always been too fussy about >> making sure that all the changes to it come from properly documented RTF >> motions. >> >> By all means use the letter of the process to allow this XMI to be >> reverted >> editorially, but for consistency, that means we should start insisting >> that >> all changes to all XMI files be completely documented in every RTF report. >> In the long run, is that better or worse than doing an Urgent Issue to >> change this file, which was implicitly signed off by the RTF and AB >> because >> it was listed in the inventory? >> >> And in any case, we still need to use a new version stamp in the new >> file's >> URL on the OMG specification site. >> >> Yours even-handedly, >> >> Andrew >> >> >> --------------------------------------------------------------- >> Manfred R. Koethe 88solutions Corporation >> tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 >> mailto: koethe@88solutions.com >> web: http://www.88solutions.com >> --------(Model-Driven Modeling Solutions)-------- >> >> >> >> >> >> >> Date: Mon, 14 Jul 2014 12:49:55 +0100 To: Tom Rutt From: Andrew Watson Subject: RE: UML 2.5 Beta 2 XMI invalid Cc: "Manfred R. Koethe" , "Rouquette, Nicolas F (313D)" , "Ed Seidewitz" , Dave Hawkins , "uml2-rtf@omg.org" , Tom Rutt X-Virus-Scanned: amavisd-new at omg.org Tom, You wrote: >> In summary, let's correct this and KEEP the version stamp as it is. This >> resolves >> this really editorial problem and has THE LEAST (NO?) tool impact. >>Changing >> the version stamp would to my knowledge at least impact >>MagicDraw 18, but >> probably others too - for no technical reasonŠ.. > again we must not confuse the package URI which is like a namespace. > > We do not need to change the package URI for this fix. > > However, how does one distinguish the old broken file from the new fixed >one > if the filename iteself for the XMI does not have a new date segment? > > Someone my use the old file instead of the fixed one if we just replace the > file in place. Fully agree. If we don't change the version stamp in the URL, we find ourselves saying things like "are you using the version of the file you downloaded from that URL before date or after date " to try to disambiguate the two different files which have the same version stamp. This is exactly the problem the version stamp was supposed to address. Giving two different files the same URL version stamp is throwing the baby out with the bathwater. It's been suggested in other contexts (FIBO) that we could have a separate "latest version" URL for all version-stamped machine-readable files that's always linked to the latest version. That seems like a good idea - anyone who always wants to see "the latest" version can embed that URL, while anyone who wants to bind to a particular version of the file and know that it will never, ever change can use the URL with the version stamp. Cheers, Andrew Date: Mon, 14 Jul 2014 12:56:06 +0100 To: Ed Seidewitz From: Andrew Watson Subject: Re: UML 2.5 Beta 2 XMI invalid Cc: Tom Rutt , "Manfred R. Koethe" , "Rouquette, Nicolas F (313D)" , Dave Hawkins , "uml2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org Ed, You wrote: > In addition, note that the filename URLs (not the namespace URIs) are >listed > on the cover of the UML 2.5 and the files so referenced are >explicitly > included as a normative part specification as stated at the end of Clause 2 > (indeed, in case of conflicts, the files take precedence). So, if we change > a file URL, we would also need to update the cover of the spec doc -- which > we seem to mean we would then really want it to be UML 2.5.1 (or just wait > until UML 2.6...). Unless we also allow this as an editorial change when >the > formal doc is published. Yes, I agree that we would need to re-issue UML 2.5 as UML 2.5.1 to change the version-stamped URL on the cover, but that's a Good Thing, since it makes it clear that Something Has Changed ... rather than just silently switching files under user's feet and hoping the change will be to their liking. Cheers, Andrew From: "Bock, Conrad" To: Andrew Watson CC: "uml2-rtf@omg.org" , "sysml-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmrw5PagIb1SK3EukjBq1EUxQnZuayrFogAS1X2uAAAfswA== Date: Mon, 14 Jul 2014 12:27:20 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.32.106] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(199002)(189002)(76482001)(74316001)(106116001)(81342001)(31966008)(85306003)(74662001)(110136001)(99396002)(76576001)(54356999)(74502001)(77096002)(50986999)(66066001)(80022001)(33646001)(101416001)(64706001)(46102001)(76176999)(21056001)(106356001)(105586002)(81542001)(86362001)(92566001)(20776003)(85852003)(83072002)(79102001)(107046002)(558084003)(93886003)(4396001)(99286002)(87936001)(95666004)(83322001)(77982001)(2656002)(108616002)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:DM2PR09MB0286;H:DM2PR09MB0285.namprd09.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;LANG:en; X-OriginatorOrg: nist.gov X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6ECRaNB031456 > Yes, I agree that we would need to re-issue UML 2.5 as UML 2.5.1 to > change the version-stamped URL on the cover, but that's a Good Thing, since it > makes it clear that Something Has Changed And a Bad Thing, SysML 1.4 depends on UML 2.5. Conrad Date: Mon, 14 Jul 2014 13:39:02 +0100 To: "Bock, Conrad" From: Andrew Watson Subject: RE: UML 2.5 Beta 2 XMI invalid Cc: "uml2-rtf@omg.org" , "sysml-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org Conrad, You wrote: > > Yes, I agree that we would need to re-issue UML 2.5 as UML 2.5.1 to > > change the version-stamped URL on the cover, but that's a Good Thing, > > since it makes it clear that Something Has Changed > > And a Bad Thing, SysML 1.4 depends on UML 2.5. If SysML 1.4 is known to work with the current UML 2.5 machine-readable files, then keeping the same files in place is a Good Thing. On the other hand, if it turns out that SysML 1.4 has flaws caused by the broken UML 2.5 files (but no-one noticed), and using UML 2.5.1 fixed those problems, we would need to rev SysML 1.4 to 1.4.1 anyway, to signal that SysML has changed. Cheers, Andrew From: "Bock, Conrad" To: Andrew Watson CC: "uml2-rtf@omg.org" , "sysml-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmrw5PagIb1SK3EukjBq1EUxQnZuayrFogAS1X2uAAAfswIAAA7oAgAAALpA= Date: Mon, 14 Jul 2014 12:40:51 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.32.106] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(189002)(199002)(52314003)(74316001)(76482001)(31966008)(85306003)(74662001)(110136001)(54356999)(76576001)(50986999)(74502001)(66066001)(33646001)(80022001)(101416001)(106356001)(46102001)(106116001)(81342001)(77096002)(76176999)(99396002)(64706001)(21056001)(86362001)(92566001)(20776003)(85852003)(83072002)(79102001)(107046002)(81542001)(4396001)(105586002)(99286002)(87936001)(93886003)(95666004)(77982001)(2656002)(83322001)(108616002)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:DM2PR09MB0287;H:DM2PR09MB0285.namprd09.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;LANG:en; X-OriginatorOrg: nist.gov X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6ECqP1x000386 > On the other hand, if it turns out that SysML 1.4 has flaws caused by > the > broken UML 2.5 files (but no-one noticed), and using UML 2.5.1 fixed > those > problems, we would need to rev SysML 1.4 to 1.4.1 anyway, to signal that > SysML has changed. Easy to say from your end. I think you need to consider production as well as consumption. :) Conrad X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZOVZmBLb c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=WLhMWes79ycA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=oCcaPWc0AAAA:8 a=qMiudbZQPS-eT9cwPDMA:9 a=wPNLvfGTeEIA:10 Date: Mon, 14 Jul 2014 13:44:20 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: "uml2-rtf@omg.org" , Andrew Watson Subject: Re: UML 2.5 Beta 2 XMI invalid X-Virus-Scanned: amavisd-new at omg.org Hi At Eclipse we have "a" releases for SNAFUs. Perhaps that's what's needed here: UML 2.5.0a. Regards Ed Willink On 14/07/2014 13:27, Bock, Conrad wrote: > Yes, I agree that we would need to re-issue UML 2.5 as UML 2.5.1 to > change the version-stamped URL on the cover, but that's a Good Thing, since it > makes it clear that Something Has Changed And a Bad Thing, SysML 1.4 depends on UML 2.5. Conrad ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7849 - Release Date: 07/14/14 X-TMN: [DfCN8p5ivAfpopTLxQSOJpQiXyfg73qL] X-Originating-Email: [stevecook@hotmail.co.uk] From: Steve Cook To: "'Bock, Conrad'" , "'Andrew Watson'" CC: , Subject: RE: UML 2.5 Beta 2 XMI invalid Date: Mon, 14 Jul 2014 14:26:30 +0100 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgME38mH52y3GQroslWb/dzzawBjHJ/vABTFQY0Au/Mr7AAQJf9qANzbTCAAMnl79AA5vi0oAFgnX0IAjnjIPAA6m6wsAO1wMCoA96hKagCIgaVpAJfiHtOfByYBYA== X-OriginalArrivalTime: 14 Jul 2014 13:26:33.0604 (UTC) FILETIME=[3AEC3440:01CF9F67] X-Virus-Scanned: amavisd-new at omg.org >I think you need to consider production as well as consumption. :) Well said. I hesitate to weigh in here, but since I have something of a personal investment in UML 2.5 I think I will. These specs are produced by volunteers with limited free time and a limited appetite for busy work. Look at what is being compared here. 1. Fix the problem in place. Keep the same file URI and version URI. Nothing else needs to change - UML 2.5, MOF 2.5, XMI 2.5, SysML 1.4, DD1.0.1. In practice I cannot think of any technical problems that could occur as a result of changing these package import IDs, which are essentially noise in the file. If somebody downloaded the current file, either they cared about the problem (Dave Hawkins) in which case they are following this conversation and will appreciate the minor fix, or they didn't, in which case the change won't affect them. Effort expended - almost none. Risks - almost none. 2. Produce new versions of UML, MOF, XMI, SysML and DD. Effort expended - many hours, costing many thousands of dollars. Impact on tool vendors - at least Manfred claims this will require NoMagic to change their latest version. Risks - confusion; morale problems - exasperating and driving away your most valuable contributors; scope for new errors to be introduced; publication delays. How is this solving any problem? This issue needs to be considered technically, weighing costs and benefits of specific solutions, not legalistically. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 14 July 2014 13:41 To: Andrew Watson Cc: uml2-rtf@omg.org; sysml-rtf@omg.org Subject: RE: UML 2.5 Beta 2 XMI invalid > On the other hand, if it turns out that SysML 1.4 has flaws caused by > the > broken UML 2.5 files (but no-one noticed), and using UML 2.5.1 fixed > those > problems, we would need to rev SysML 1.4 to 1.4.1 anyway, to signal that > SysML has changed. Easy to say from your end. I think you need to consider production as well as consumption. :) Conrad From: Pete Rivett To: Andrew Watson , Ed Seidewitz CC: Tom Rutt , "Manfred R. Koethe" , "Rouquette, Nicolas F (313D)" , Dave Hawkins , "uml2-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: Ac+dNbYgHp/RXbrTT0SwdbEcinj91AAxo+LdAA8HlYAAACTOAAADtOgAAFNeVwAACet4oA== Date: Mon, 14 Jul 2014 14:14:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.231.217.60] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6EEED3I004817 > hoping the change will be to their liking. We don't need to hope - there's zero chance anyone would not like a structurally invalid file to be replaced by a valid one! We just need to explain in the file itself what we've done. XMI does have documentation elements (though one would not tell from the lack of use they get). -----Original Message----- From: Andrew Watson [mailto:andrew@omg.org] Sent: Monday, July 14, 2014 4:56 AM To: Ed Seidewitz Cc: Tom Rutt; Manfred R. Koethe; Rouquette, Nicolas F (313D); Dave Hawkins; uml2-rtf@omg.org Subject: Re: UML 2.5 Beta 2 XMI invalid Ed, You wrote: > In addition, note that the filename URLs (not the namespace URIs) are >listed > on the cover of the UML 2.5 and the files so referenced are >explicitly included as a normative part specification as stated at the >end of Clause 2 (indeed, in case of conflicts, the files take >precedence). So, if we change a file URL, we would also need to update >the cover of the spec doc -- which we seem to mean we would then >really want it to be UML 2.5.1 (or just wait until UML 2.6...). Unless >we also allow this as an editorial change when the > formal doc is >published. Yes, I agree that we would need to re-issue UML 2.5 as UML 2.5.1 to change the version-stamped URL on the cover, but that's a Good Thing, since it makes it clear that Something Has Changed ... rather than just silently switching files under user's feet and hoping the change will be to their liking. Cheers, Andrew Subject: Re: UML 2.5 Beta 2 XMI invalid From: Stephen J Mellor Date: Mon, 14 Jul 2014 15:19:09 +0100 Cc: Watson Andrew , Ed Seidewitz , Tom Rutt , Koethe Manfred , "Rouquette, Nicolas F (313D)" , Dave Hawkins , "uml2-rtf@omg.org" To: Rivett Pete X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6EEJVdE005088 On 2014 Jul 14, at 15:14, Pete Rivett wrote: >> hoping the change will be to their liking. > > We don't need to hope - there's zero chance anyone would not like a structurally invalid file to be replaced by a valid one! > We just need to explain in the file itself what we've done. XMI does have documentation elements (though one would not tell from the lack of use they get). > > -----Original Message----- > From: Andrew Watson [mailto:andrew@omg.org] > Sent: Monday, July 14, 2014 4:56 AM > To: Ed Seidewitz > Cc: Tom Rutt; Manfred R. Koethe; Rouquette, Nicolas F (313D); Dave Hawkins; uml2-rtf@omg.org > Subject: Re: UML 2.5 Beta 2 XMI invalid > > Ed, > > You wrote: > >> In addition, note that the filename URLs (not the namespace URIs) are >> listed > on the cover of the UML 2.5 and the files so referenced are >> explicitly included as a normative part specification as stated at the >> end of Clause 2 (indeed, in case of conflicts, the files take >> precedence). So, if we change a file URL, we would also need to update >> the cover of the spec doc -- which we seem to mean we would then >> really want it to be UML 2.5.1 (or just wait until UML 2.6...). Unless >> we also allow this as an editorial change when the > formal doc is >> published. > > Yes, I agree that we would need to re-issue UML 2.5 as UML 2.5.1 to change the version-stamped URL on the cover, but that's a Good Thing, since it makes it clear that Something Has Changed ... rather than just silently switching files under user's feet and hoping the change will be to their liking. > > Cheers, > > Andrew > > From: Pete Rivett To: Steve Cook , "'Bock, Conrad'" , "'Andrew Watson'" , "Tom Rutt (tom@coastin.com)" CC: "uml2-rtf@omg.org" , "sysml-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: Ac+dNbYgHp/RXbrTT0SwdbEcinj91AAxo+LdAA8HlYAAACTOAAADtOgAAFNeVwAAARc/AAAAaJsAAAAQPoAAAZglAAAOVSTA Date: Mon, 14 Jul 2014 14:08:32 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.231.217.60] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6EE8mYE004499 I agree with Steve (and others): I think it's sufficient to have a new OMG document number and also of course a comment in the xmi:Documentation element of the XMI file to say what we've done. In this case there's no earthly reason anyone would want to reference the old file - because it's fundamentally invalid. As an aside, I think UML (and other specs) should go the way of FIBO and have a non-dated URL for referencing that gets redirected to the latest file whenever it's updated. Even for cases when the file has been significantly updated, the referrer normally does not care. In most cases a Profile or Model does not care whether it references the UML 2.4 or the UML 2.5 version of UseCase. And the dated URL is still available for those that do care. The same for namespaces: they should not be updated unless there is something fundamentally incompatible. For example W3 kept the same namespace http://www.w3.org/2002/07/owl# for OWL 2 as for OWL 1 despite it containing a huge number of significant changes. See policy here http://www.w3.org/2005/07/13-nsuri#nsdoc and examples http://www.w3.org/ns/ws-policy/ and the following for XML itself (which retained the same namespace at version 1.1) http://www.w3.org/XML/1998/namespace and http://www.w3.org/2001/xml.xsd : Pete -----Original Message----- From: Steve Cook [mailto:stevecook@hotmail.co.uk] Sent: Monday, July 14, 2014 6:27 AM To: 'Bock, Conrad'; 'Andrew Watson' Cc: uml2-rtf@omg.org; sysml-rtf@omg.org Subject: RE: UML 2.5 Beta 2 XMI invalid >I think you need to consider production as well as consumption. :) Well said. I hesitate to weigh in here, but since I have something of a personal investment in UML 2.5 I think I will. These specs are produced by volunteers with limited free time and a limited appetite for busy work. Look at what is being compared here. 1. Fix the problem in place. Keep the same file URI and version URI. Nothing else needs to change - UML 2.5, MOF 2.5, XMI 2.5, SysML 1.4, DD1.0.1. In practice I cannot think of any technical problems that could occur as a result of changing these package import IDs, which are essentially noise in the file. If somebody downloaded the current file, either they cared about the problem (Dave Hawkins) in which case they are following this conversation and will appreciate the minor fix, or they didn't, in which case the change won't affect them. Effort expended - almost none. Risks - almost none. 2. Produce new versions of UML, MOF, XMI, SysML and DD. Effort expended - many hours, costing many thousands of dollars. Impact on tool vendors - at least Manfred claims this will require NoMagic to change their latest version. Risks - confusion; morale problems - exasperating and driving away your most valuable contributors; scope for new errors to be introduced; publication delays. How is this solving any problem? This issue needs to be considered technically, weighing costs and benefits of specific solutions, not legalistically. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 14 July 2014 13:41 To: Andrew Watson Cc: uml2-rtf@omg.org; sysml-rtf@omg.org Subject: RE: UML 2.5 Beta 2 XMI invalid > On the other hand, if it turns out that SysML 1.4 has flaws caused by > the > broken UML 2.5 files (but no-one noticed), and using UML 2.5.1 fixed > those > problems, we would need to rev SysML 1.4 to 1.4.1 anyway, > to signal that > SysML has changed. Easy to say from your end. I think you need to consider production as well as consumption. :) Conrad Subject: Re: UML 2.5 Beta 2 XMI invalid From: "Manfred R. Koethe" Date: Mon, 14 Jul 2014 09:16:54 -0700 Cc: "Bock, Conrad" , Steve Cook , uml2-rtf@omg.org, " (sysml-rtf@omg.org)" To: Andrew Watson X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V02:K0:czOpJt6JPIiAZZoRf/OY+TJeXBbrwII8liaIixOx901 h0bDnFAgeGVXbW/WU5yTJ2oQn2X5LfOzrHlMIbHcdwCLF8ECtC KuI+8kAyP5TWjgNleJVjMEmd+dMntuw8/jSn0iDnGdYTlBWk3u drk/LWQwyqN+0XTdxdlZ/2E+dAwbsKVv/fwl2SiCohuOXfDG3E DTCxmfQfUzdOc1hERxYIHysBy0XJY7h8En+UTJN+c0IU5/PXKv gYfC8vY2G522/3+pe+fEKyM3UcVaoxXB81G4sXGU4u+C7V9PjB l0HjNlwOkF2ANLrKci13k2knwG/SCQ+yYxXuUtUwXy3mddT7K7 Hnn1+DkAhrYXkBO4/AV6CwPZuOO3ne2pcX/IUse6ML9+WRkuCW cIgBs8wjxy+Ue1Qd7wwS1NrARXS+jP7ViQ= X-Virus-Scanned: amavisd-new at omg.org Andrew, Let’s please just correct the files, but keep version stamp and URL untouched. As Pete suggested, let’s add a comment saying what was corrected. This is the only way to avoid a ripple effect for absolutely no technical reason. (Even your famous school teacher would agree here). The statement is essentially a processing directive saying that package containing that directive shall import the package specified in the importedPackage=“….” attribute. As being such a pure processing directive, any sane model will never reference such a packageImport statement. The fact that it has an xmi:id=“…” is for pure syntax reasons. Any problem with these particular ids is purely cosmetic, or a distortion of the noise those ids represent by Steve’s definition. No user application should ever be affected by this cosmetic error, so please let’s correct just that cosmetic and let’s the technically important facts, like version stamp, URL, document front page, etc., untouched. Thank you, Manfred On Jul 14, 2014, at 06:26 , Steve Cook wrote: I think you need to consider production as well as consumption. :) Well said. I hesitate to weigh in here, but since I have something of a personal investment in UML 2.5 I think I will. These specs are produced by volunteers with limited free time and a limited appetite for busy work. Look at what is being compared here. 1. Fix the problem in place. Keep the same file URI and version URI. Nothing else needs to change - UML 2.5, MOF 2.5, XMI 2.5, SysML 1.4, DD1.0.1. In practice I cannot think of any technical problems that could occur as a result of changing these package import IDs, which are essentially noise in the file. If somebody downloaded the current file, either they cared about the problem (Dave Hawkins) in which case they are following this conversation and will appreciate the minor fix, or they didn't, in which case the change won't affect them. Effort expended - almost none. Risks - almost none. 2. Produce new versions of UML, MOF, XMI, SysML and DD. Effort expended - many hours, costing many thousands of dollars. Impact on tool vendors - at least Manfred claims this will require NoMagic to change their latest version. Risks - confusion; morale problems - exasperating and driving away your most valuable contributors; scope for new errors to be introduced; publication delays. How is this solving any problem? This issue needs to be considered technically, weighing costs and benefits of specific solutions, not legalistically. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 14 July 2014 13:41 To: Andrew Watson Cc: uml2-rtf@omg.org; sysml-rtf@omg.org Subject: RE: UML 2.5 Beta 2 XMI invalid On the other hand, if it turns out that SysML 1.4 has flaws caused by > the > broken UML 2.5 files (but no-one noticed), and using UML 2.5.1 fixed those > problems, we would need to rev SysML 1.4 to 1.4.1 anyway, to signal that > SysML has changed. Easy to say from your end. I think you need to consider production as well as consumption. :) Conrad --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)------- Date: Mon, 14 Jul 2014 17:27:17 +0100 From: Dave Hawkins Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 To: Pete Rivett , Steve Cook , "'Bock, Conrad'" , "'Andrew Watson'" , "Tom Rutt (tom@coastin.com)" CC: "uml2-rtf@omg.org" , "sysml-rtf@omg.org" Subject: Re: UML 2.5 Beta 2 XMI invalid X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Virus-Scanned: amavisd-new at omg.org I think one of the problems here is the overloading of the version number. It's both being used to distinguish between different versions of the document and different versions of the specification. And neither of those version numbers are present in the document itself, which makes it difficult to determine whether any copy you have is the correct one. In the short-term, for this particular case, I think Pete's solution of including a comment in the file is the right one. Longer-term I think there need to be some changes to the XMI spec to ensure that documents can contain their identifiers and that there is a policy in place for when each of them should be used for references. I'm not sure what FIBO actually is. However, I think some care is needed when using a 'latest' reference. How do you handle non-backwards-compatible changes? For example, you may need to migrate data in some way. If you don't know which version was being referenced, you might not be able to determine the required changes. Additionally, you need to ensure that object identifiers are preserved for all time, because otherwise they could be ambiguous. Finally, I find the date based version numbers very unhelpful. It's unnecessarily confusing when looking at XMI documents and trying to work out which version you're actually dealing with. I would much rather namespaces and references used a major.minor approach. Cheers, Dave On 14/07/2014 15:08, Pete Rivett wrote: I agree with Steve (and others): I think it's sufficient to have a new OMG document number and also of course a comment in the xmi:Documentation element of the XMI file to say what we've done. In this case there's no earthly reason anyone would want to reference the old file - because it's fundamentally invalid. As an aside, I think UML (and other specs) should go the way of FIBO and have a non-dated URL for referencing that gets redirected to the latest file whenever it's updated. Even for cases when the file has been significantly updated, the referrer normally does not care. In most cases a Profile or Model does not care whether it references the UML 2.4 or the UML 2.5 version of UseCase. And the dated URL is still available for those that do care. The same for namespaces: they should not be updated unless there is something fundamentally incompatible. For example W3 kept the same namespace http://www.w3.org/2002/07/owl# for OWL 2 as for OWL 1 despite it containing a huge number of significant changes. See policy here http://www.w3.org/2005/07/13-nsuri#nsdoc and examples http://www.w3.org/ns/ws-policy/ and the following for XML itself (which retained the same namespace at version 1.1) http://www.w3.org/XML/1998/namespace and http://www.w3.org/2001/xml.xsd : Pete -----Original Message----- From: Steve Cook [mailto:stevecook@hotmail.co.uk] Sent: Monday, July 14, 2014 6:27 AM To: 'Bock, Conrad'; 'Andrew Watson' Cc: uml2-rtf@omg.org; sysml-rtf@omg.org Subject: RE: UML 2.5 Beta 2 XMI invalid I think you need to consider production as well as consumption. :) Well said. I hesitate to weigh in here, but since I have something of a personal investment in UML 2.5 I think I will. These specs are produced by volunteers with limited free time and a limited appetite for busy work. Look at what is being compared here. 1. Fix the problem in place. Keep the same file URI and version URI. Nothing else needs to change - UML 2.5, MOF 2.5, XMI 2.5, SysML 1.4, DD1.0.1. In practice I cannot think of any technical problems that could occur as a result of changing these package import IDs, which are essentially noise in the file. If somebody downloaded the current file, either they cared about the problem (Dave Hawkins) in which case they are following this conversation and will appreciate the minor fix, or they didn't, in which case the change won't affect them. Effort expended - almost none. Risks - almost none. 2. Produce new versions of UML, MOF, XMI, SysML and DD. Effort expended - many hours, costing many thousands of dollars. Impact on tool vendors - at least Manfred claims this will require NoMagic to change their latest version. Risks - confusion; morale problems - exasperating and driving away your most valuable contributors; scope for new errors to be introduced; publication delays. How is this solving any problem? This issue needs to be considered technically, weighing costs and benefits of specific solutions, not legalistically. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 14 July 2014 13:41 To: Andrew Watson Cc: uml2-rtf@omg.org; sysml-rtf@omg.org Subject: RE: UML 2.5 Beta 2 XMI invalid > On the other hand, if it turns out that SysML 1.4 has flaws caused by > the > broken UML 2.5 files (but no-one noticed), and using UML 2.5.1 fixed those > problems, we would need to rev SysML 1.4 to 1.4.1 anyway, to signal that > SysML has changed. Easy to say from your end. I think you need to consider production as well as consumption. :) Conrad From: Pete Rivett To: Dave Hawkins , Steve Cook , "'Bock, Conrad'" , "'Andrew Watson'" , "Tom Rutt (tom@coastin.com)" CC: "uml2-rtf@omg.org" , "sysml-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: Ac+dNbYgHp/RXbrTT0SwdbEcinj91AAxo+LdAA8HlYAAACTOAAADtOgAAFNeVwAAARc/AAAAaJsAAAAQPoAAAZglAAAOVSTA//+/2YCAAGcXAA== Date: Mon, 14 Jul 2014 17:26:22 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.231.217.60] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6EHQdaK016501 > And neither of those version numbers are present in the document itself, which makes it difficult to determine whether any copy you have is the correct one. I've been trying for over a decade to get specifications to use XMI Documentation elements for this purpose. There is no change needed in the XMI spec itself: just an OMG specification publication policy. > I'm not sure what FIBO actually is. Financial Industry Business Ontology. http://www.omg.org/hot-topics/fibo.htm > However, I think some care is needed when using a 'latest' reference. How do you handle non-backwards-compatible changes? Agreed. Though in the FIBO case the policy is to avoid non-backwards-compatible changes. > Additionally, you need to ensure that object identifiers are preserved for all time, because otherwise they could be ambiguous. Again agreed: but FIBO is an ontology that uses full URIs for object identifiers. And UML has specifically taken trouble to make its xmi:ids persistent. > It's unnecessarily confusing when looking at XMI documents and trying to work out which version you're actually dealing with. I would much rather namespaces and references used a major.minor approach. That resulted in unnecessary impact when a new version of UML resulted in no metamodel changes. And forward-compatible changes would also be fine as I argued. Pete -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, July 14, 2014 9:27 AM To: Pete Rivett; Steve Cook; 'Bock, Conrad'; 'Andrew Watson'; Tom Rutt (tom@coastin.com) Cc: uml2-rtf@omg.org; sysml-rtf@omg.org Subject: Re: UML 2.5 Beta 2 XMI invalid I think one of the problems here is the overloading of the version number. It's both being used to distinguish between different versions of the document and different versions of the specification. And neither of those version numbers are present in the document itself, which makes it difficult to determine whether any copy you have is the correct one. In the short-term, for this particular case, I think Pete's solution of including a comment in the file is the right one. Longer-term I think there need to be some changes to the XMI spec to ensure that documents can contain their identifiers and that there is a policy in place for when each of them should be used for references. I'm not sure what FIBO actually is. However, I think some care is needed when using a 'latest' reference. How do you handle non-backwards-compatible changes? For example, you may need to migrate data in some way. If you don't know which version was being referenced, you might not be able to determine the required changes. Additionally, you need to ensure that object identifiers are preserved for all time, because otherwise they could be ambiguous. Finally, I find the date based version numbers very unhelpful. It's unnecessarily confusing when looking at XMI documents and trying to work out which version you're actually dealing with. I would much rather namespaces and references used a major.minor approach. Cheers, Dave On 14/07/2014 15:08, Pete Rivett wrote: > I agree with Steve (and others): I think it's sufficient to have a new OMG document number and also of course a comment in the xmi:Documentation element of the XMI file to say what we've done. > In this case there's no earthly reason anyone would want to reference the old file - because it's fundamentally invalid. > > As an aside, I think UML (and other specs) should go the way of FIBO and have a non-dated URL for referencing that gets redirected to the latest file whenever it's updated. Even for cases when the file has been significantly updated, the referrer normally does not care. In most cases a Profile or Model does not care whether it references the UML 2.4 or the UML 2.5 version of UseCase. And the dated URL is still available for those that do care. > The same for namespaces: they should not be updated unless there is something fundamentally incompatible. > For example W3 kept the same namespace http://www.w3.org/2002/07/owl# for OWL 2 as for OWL 1 despite it containing a huge number of significant changes. > See policy here http://www.w3.org/2005/07/13-nsuri#nsdoc and examples http://www.w3.org/ns/ws-policy/ and the following for XML itself (which retained the same namespace at version 1.1) http://www.w3.org/XML/1998/namespace and http://www.w3.org/2001/xml.xsd : > > Pete > > -----Original Message----- > From: Steve Cook [mailto:stevecook@hotmail.co.uk] > Sent: Monday, July 14, 2014 6:27 AM > To: 'Bock, Conrad'; 'Andrew Watson' > Cc: uml2-rtf@omg.org; sysml-rtf@omg.org > Subject: RE: UML 2.5 Beta 2 XMI invalid > >> I think you need to consider production as well as consumption. :) > > Well said. I hesitate to weigh in here, but since I have something of a > personal investment in UML 2.5 I think I will. These specs are produced by volunteers with limited free time and a limited appetite for busy work. > Look at what is being compared here. > > 1. Fix the problem in place. Keep the same file URI and version URI. > Nothing else needs to change - UML 2.5, MOF 2.5, XMI 2.5, SysML 1.4, DD1.0.1. In practice I cannot think of any technical problems that could occur as a result of changing these package import IDs, which are essentially noise in the file. If somebody downloaded the current file, either they cared about the problem (Dave Hawkins) in which case they are following this conversation and will appreciate the minor fix, or they didn't, in which case the change won't affect them. Effort expended - almost none. Risks - almost none. > > 2. Produce new versions of UML, MOF, XMI, SysML and DD. Effort expended - > many hours, costing many thousands of dollars. Impact on tool vendors - at least Manfred claims this will require NoMagic to change their latest version. Risks - confusion; morale problems - exasperating and driving away your most valuable contributors; scope for new errors to be introduced; publication delays. How is this solving any problem? > > This issue needs to be considered technically, weighing costs and benefits of specific solutions, not legalistically. > > -- Steve > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: 14 July 2014 13:41 > To: Andrew Watson > Cc: uml2-rtf@omg.org; sysml-rtf@omg.org > Subject: RE: UML 2.5 Beta 2 XMI invalid > > > On the other hand, if it turns out that SysML 1.4 has flaws > caused by > the > broken UML 2.5 files (but no-one noticed), and > using UML 2.5.1 fixed >> those > problems, we would need to rev SysML 1.4 to 1.4.1 anyway, >> to > signal that > SysML has changed. > > Easy to say from your end. I think you need to consider production as > well as consumption. :) > > Conrad > Date: Wed, 16 Jul 2014 09:00:30 +0100 To: Pete Rivett From: Andrew Watson Subject: RE: UML 2.5 Beta 2 XMI invalid Cc: "Manfred R. Koethe" , "Bock, Conrad" , Steve Cook , "uml2-rtf@omg.org" , " (sysml-rtf@omg.org)" X-Virus-Scanned: amavisd-new at omg.org Pete, You wrote: >> what are the universal, objective, written criteria that my famous >> primary school teacher would follow to work out when it's OK to keep the >> same version stamp on a machine-readable file, and when it isn't? > The W3C policies I previously quoted seem to be a good start, though > would need minor updates to apply to the larger breadth of artifacts that > OMG deals with. To remind you we have: > http://www.w3.org/2005/07/13-nsuri#nsdoc > general policy which gives a few options. The equivalent of Candidate > Recommendation in OMG would be Beta spec. Example (3) seems appropriate > for OMG once spec is adopted (Beta): > > "This namespace URI may be reused in any update of the specification > which is made for the purpose of clarification or bug fixes. These changes > will be minor in that they do not (a) change the meaning or validity of > existing documents written using the namespace, or (b) affect the > operation of existing software written to process such documents." That definition does indeed sound reasonable in general, but it cannot be applied here for two interrelated reasons. Firstly, it glosses over the possibility that a replacement file that fixes this problem will instead contain other bugs. Given that the current bug went unnoticed for at least 9 months, there's a nonzero probability this will happen. A tool that copes with this bug may choke on a replacement file because of some other, equally unintentional bug that slips into it. This is part of the second, wider problem. If we could collect together all the tools that use this file and check that they all played well with its replacement, we could assure ourselves that the replacement file is completely compatible with respect to every tool, as this W3C policy describes. However, that's obviously impossible. This XMI file has been posted on the public internet for at least six months, so there can be no complete list of "existing software" has been created that depends on it. Because there is no such list, we can never prove that condition (b) is satisfied for a replacement file. Hence this W3C policy nicely illustrates why we *must* change the version stamp whenever we change a published machine-readable file. Cheers, Andrew X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZOVZmBLb c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=WLhMWes79ycA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=SSmOFEACAAAA:8 a=o1tfDrdaDP9gZZ5TYUAA:9 a=e2ktSmc_8P842l2s:21 a=ol1S4cbEHU67ckhc:21 a=wPNLvfGTeEIA:10 Date: Wed, 16 Jul 2014 09:34:04 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Andrew Watson CC: "uml2-rtf@omg.org" Subject: Re: UML 2.5 Beta 2 XMI invalid X-Antivirus: AVG for E-mail 2014.0.4716 [3986/7858] X-Virus-Scanned: amavisd-new at omg.org Hi Andrew I am sorry, I have to agree with Steve. OMG credibility must be considered more generally. If OMG cannot fix stupid unarguable bugs, OMG becomes less relevant. Obviously any software application that has a security checksum hardcoded for any incoming standards file will be sensitive to any change so it is impossible for any change to be undetectable by all applications. We need to be more pragmatic. This change is in an element that 99% of plausible applications will ignore. Only conformance checking applications would maintain a mapping of all xmi:ids and these should barf on the existing content. So the 1% that might notice will be grateful. (After 9 months, may be its 99.99% of users who won't notice and 0.01% who will be pleased.) Since this is a cure for a SNAFU that I am sure all the RTF will certify is non-damaging, let there be a UML 2.5.0a to accommodate it. "a" a fix that is applicable to all usage without respecification by the dependants. Regards Ed Willink On 16/07/2014 09:00, Andrew Watson wrote: Pete, You wrote: what are the universal, objective, written criteria that my famous primary school teacher would follow to work out when it's OK to keep the same version stamp on a machine-readable file, and when it isn't? The W3C policies I previously quoted seem to be a good start, though would need minor updates to apply to the larger breadth of artifacts that OMG deals with. To remind you we have: http://www.w3.org/2005/07/13-nsuri#nsdoc general policy which gives a few options. The equivalent of Candidate Recommendation in OMG would be Beta spec. Example (3) seems appropriate for OMG once spec is adopted (Beta): "This namespace URI may be reused in any update of the specification which is made for the purpose of clarification or bug fixes. These changes will be minor in that they do not (a) change the meaning or validity of existing documents written using the namespace, or (b) affect the operation of existing software written to process such documents." That definition does indeed sound reasonable in general, but it cannot be applied here for two interrelated reasons. Firstly, it glosses over the possibility that a replacement file that fixes this problem will instead contain other bugs. Given that the current bug went unnoticed for at least 9 months, there's a nonzero probability this will happen. A tool that copes with this bug may choke on a replacement file because of some other, equally unintentional bug that slips into it. This is part of the second, wider problem. If we could collect together all the tools that use this file and check that they all played well with its replacement, we could assure ourselves that the replacement file is completely compatible with respect to every tool, as this W3C policy describes. However, that's obviously impossible. This XMI file has been posted on the public internet for at least six months, so there can be no complete list of "existing software" has been created that depends on it. Because there is no such list, we can never prove that condition (b) is satisfied for a replacement file. Hence this W3C policy nicely illustrates why we *must* change the version stamp whenever we change a published machine-readable file. Cheers, Andrew Date: Wed, 16 Jul 2014 10:04:16 +0100 To: Ed Willink From: Andrew Watson Subject: Re: UML 2.5 Beta 2 XMI invalid Cc: "uml2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org Ed, You wrote: > I am sorry, I have to agree with Steve. OMG credibility must be > considered more generally. If OMG cannot fix stupid unarguable bugs, OMG > becomes less relevant. Don't be sorry - I agree with you. We should fix this bug. I'm certainly *not* arguing that we should not. I *am* arguing that we should fix it in an open and visible way, by publishing a new XMI file with a new version stamp. > Since this is a cure for a SNAFU that I am sure all the RTF will certify > is non-damaging, let there be a UML 2.5.0a to accommodate it. "a" a fix > that is applicable to all usage without respecification by the dependants. We would normally call this "UML 2.5.1". Is there any useful distinction between calling it "2.5.1" and "2.5.0a"? Cheers, Andrew X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZOVZmBLb c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=WLhMWes79ycA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=s3iH9eAIQp06CcP6da4A:9 a=wPNLvfGTeEIA:10 Date: Wed, 16 Jul 2014 10:44:43 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Andrew Watson CC: "uml2-rtf@omg.org" Subject: Re: UML 2.5 Beta 2 XMI invalid X-Antivirus: AVG for E-mail 2014.0.4716 [3986/7861] X-Virus-Scanned: amavisd-new at omg.org Hi Andrew Yes. I think there is an important difference. 2.5.1 might pick up emergency issues and so might change a semantic and consequently all dependants must explicitly accept the consequence. 2.5.0a is an Oh SH**t, we really messed up. 2.5.0a is an unarguable replacement for 2.5.0 and so dependants are not affected. Regards Ed Willink On 16/07/2014 10:04, Andrew Watson wrote: Ed, You wrote: I am sorry, I have to agree with Steve. OMG credibility must be considered more generally. If OMG cannot fix stupid unarguable bugs, OMG becomes less relevant. Don't be sorry - I agree with you. We should fix this bug. I'm certainly *not* arguing that we should not. I *am* arguing that we should fix it in an open and visible way, by publishing a new XMI file with a new version stamp. Since this is a cure for a SNAFU that I am sure all the RTF will certify is non-damaging, let there be a UML 2.5.0a to accommodate it. "a" a fix that is applicable to all usage without respecification by the dependants. We would normally call this "UML 2.5.1". Is there any useful distinction between calling it "2.5.1" and "2.5.0a"? Cheers, Andrew Date: Wed, 16 Jul 2014 14:13:55 +0100 To: Ed Willink From: Andrew Watson Subject: Re: UML 2.5 Beta 2 XMI invalid Cc: "uml2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org Ed, You wrote: > Yes. I think there is an important difference. > > 2.5.1 might pick up emergency issues and so might change a semantic and > consequently all dependants must explicitly accept the consequence. > > 2.5.0a is an Oh SH**t, we really messed up. 2.5.0a is an unarguable > replacement for 2.5.0 and so dependants are not affected. There's no danger that a UML 2.5.1 revision to fix this problem will be forced to include any other fixes - unless we want it to. Normally "dot dot" releases like UML 2.5.1 are the result of applying urgent issue resolutions. We (i.e. the RTF, supported by me) choose exactly what issues are declared "Urgent", and exactly which urgent issues resolution(s) to put into a UML 2.5.1 "dot dot" revision. So if we go down the urgent issue route, we can restrict UML 2.5.1 to including just a fix for this problem, and not pick up any other changes. On the other hand, in this case Ed Seidewitz has argued that the mistake arose when the UML 2.5 FTF's decisions accidentally weren't implemented properly. Under these circumstances the fix could be implemented by a different route - if someone puts a revised XMI file in my hands and I have assurances that it just unwinds the editing mistake to more-correctly implement the FTF's decisions, then I can unilaterally replace the XMI file without consulting the current UML 2.6 RTF. I normally would not usurp the RTF in this way - I usually only use this route if there's no extant RTF and no other route to correcting the problem. I would much prefer the RTF to vote on the fix, to show that they'd vetted it and were happy. However, we could use this route if absolutely necessary, and once again, there's no requirement to include any other changes in the resulting UML 2.5.1 revision if we don't want to. So unless there's something else we've missed (?), I don't think there's a need to change established OMG practice and publish this fix as UML 2.5.0a rather than UML 2.5.1. Cheers, Andrew From: "BERNARD, Yves" To: Andrew Watson CC: "uml2-rtf@omg.org" Date: Wed, 16 Jul 2014 15:37:25 +0200 Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: Ac+g97U7GQde86tVQ52aZbZ2JmAb+AAAuP1g Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6GDbY15022686 Andrew, >- if someone puts a revised XMI file in my hands and I have assurances that it >just unwinds the editing mistake to more-correctly implement the FTF's >decisions, then I can unilaterally replace the XMI file without consulting the >current UML 2.6 RTF. [BERNARD, Yves] I think an XML diff tool could help in checking that only the offended IDs are modified Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Ed Seidewitz To: Andrew Watson CC: Ed Willink , "uml2-rtf@omg.org" Subject: Re: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmfxKmLaDNAfdWE6FagL1NnIQVpubDuSA///4/gCAAHGoAIABjhYA//+/1/GAAAEm2oAAHahfgAQbAgCAAWNVDIAAS+AAgAAIcACAAAtNgIAAOnOA///SnPc= Date: Wed, 16 Jul 2014 14:31:26 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailprotector-Decision: deliver X-Mailprotector-Original-Sender: ed-s@modeldriven.com X-Mailprotector-Original-Recipients: andrew@omg.org, ed@willink.me.uk, uml2-rtf@omg.org X-Mailprotector-Redirect-To: ed-s@modeldriven.com X-Mailprotector-Connection: TLSv1|cas203.mailprotector.com|54.208.113.85|CAS203.mailprotector.local|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: clean X-Mailprotector-Score: 0 X-Mailprotector-IP-Analysis: 0, 54.208.113.85, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-9663-c X-Mailprotector-ID: f4e8130c-5deb-4f54-9b5c-dadbb4ea29cf X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6GEVaaT026653 I have already produced a corrected XMI file, which restores all the XMI IDs in question to what they where in the Beta 1 version. It was sent out somewhere along this email thread. I did not include an xmi:Documentation element, as Pete suggested, but I can add that. I think there is some consensus that, whatever we do, we should leave the namespace URI the same. The remaining questions are whether to give the corrected file a new file URI and whether to revise the UML version number to 2.5.1. If we change the file URL, then we also need to update the file URL list on the cover page of the UML spec document, regardless if whether we update the version number. I would personally prefer that the file be updated in place, with no URL change. However, if the URL changes, then I would prefer that it the document cover just be updated editorially for the formal doc, with no version number rev. But I believe Andrew says that both the file URL must change and the UML version number must be revised to 2.5.1. In this case we would never issue UML 2.5 formally, just 2.5.1 with the new file. And then we might as well have the RTF vote on this as an urgent issue. Perhaps this isn't so bad, if we can do it without further delaying the production of the UML 2.5.x formal doc. But it does seem rather heavyweight for correcting a clearly inadvertent technical production error. Though I t's all probably a lot bigger deal whatever we do for us than anyone outside of OMG, anyway! Ed Sent from my iPhone > On Jul 16, 2014, at 9:15 AM, "Andrew Watson" wrote: > > Ed, > > You wrote: > >> Yes. I think there is an important difference. >> >> 2.5.1 might pick up emergency issues and so might change a semantic and >> consequently all dependants must explicitly accept the consequence. >> >> 2.5.0a is an Oh SH**t, we really messed up. 2.5.0a is an unarguable >> replacement for 2.5.0 and so dependants are not affected. > > There's no danger that a UML 2.5.1 revision to fix this problem will be > forced to include any other fixes - unless we want it to. > > Normally "dot dot" releases like UML 2.5.1 are the result of applying > urgent issue resolutions. We (i.e. the RTF, supported by me) choose exactly > what issues are declared "Urgent", and exactly which urgent issues > resolution(s) to put into a UML 2.5.1 "dot dot" revision. So if we go down > the urgent issue route, we can restrict UML 2.5.1 to including just a fix > for this problem, and not pick up any other changes. > > On the other hand, in this case Ed Seidewitz has argued that the mistake > arose when the UML 2.5 FTF's decisions accidentally weren't implemented > properly. Under these circumstances the fix could be implemented by a > different route - if someone puts a revised XMI file in my hands and I have > assurances that it just unwinds the editing mistake to more-correctly > implement the FTF's decisions, then I can unilaterally replace the XMI file > without consulting the current UML 2.6 RTF. I normally would not usurp the > RTF in this way - I usually only use this route if there's no extant RTF > and no other route to correcting the problem. I would much prefer the RTF > to vote on the fix, to show that they'd vetted it and were happy. However, > we could use this route if absolutely necessary, and once again, there's no > requirement to include any other changes in the resulting UML 2.5.1 > revision if we don't want to. > > So unless there's something else we've missed (?), I don't think there's a > need to change established OMG practice and publish this fix as UML 2.5.0a > rather than UML 2.5.1. > > Cheers, > > Andrew > From: "Bock, Conrad" To: Andrew Watson CC: "uml2-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmrw5PagIb1SK3EukjBq1EUxQnZubDuSA///4/gCAAHGoAIABjhYA//+/1/GAAAEm2oAAHahfgAQbAgCAAWNVDIAAS+AAgAAIcACAAAtNgIAAOnOA///SnPcAALdkkA== Date: Wed, 16 Jul 2014 15:00:22 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.32.106] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(199002)(189002)(106356001)(77096002)(31966008)(54356999)(106116001)(66066001)(50986999)(21056001)(76176999)(81342001)(85306003)(74316001)(74662001)(46102001)(101416001)(99396002)(80022001)(86362001)(85852003)(4396001)(20776003)(74502001)(92566001)(79102001)(107046002)(558084003)(83072002)(81542001)(105586002)(83322001)(110136001)(93886003)(76576001)(76482001)(64706001)(2656002)(87936001)(95666004)(99286002)(33646002)(77982001)(108616002)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:DM2PR09MB0287;H:DM2PR09MB0285.namprd09.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;LANG:en; X-OriginatorOrg: nist.gov X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6GF0YPF028418 Andrew, Perhaps I misread your previous mail, but since UML 2.5 isn't formally available yet, why would a 2.5.1 be needed to bring 2.5 Beta 2 documents/artifacts in line with FTF decisions? Conrad From: "Bock, Conrad" To: Andrew Watson CC: "uml2-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmrw5PagIb1SK3EukjBq1EUxQnZubDuSA///4/gCAAHGoAIABjhYA//+/1/GAAAEm2oAAHahfgAQbAgCAAWNVDIAAS+AAgAAIcACAAAtNgIAAOnOA///SnPcAALdkkA== Date: Wed, 16 Jul 2014 15:02:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.32.106] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(199002)(189002)(106356001)(77096002)(31966008)(54356999)(106116001)(66066001)(50986999)(21056001)(76176999)(81342001)(85306003)(74316001)(74662001)(46102001)(101416001)(99396002)(80022001)(86362001)(85852003)(4396001)(20776003)(74502001)(92566001)(79102001)(107046002)(558084003)(83072002)(81542001)(105586002)(83322001)(110136001)(93886003)(76576001)(76482001)(64706001)(2656002)(87936001)(95666004)(99286002)(33646002)(77982001)(108616002)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:DM2PR09MB0287;H:DM2PR09MB0285.namprd09.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;LANG:en; X-OriginatorOrg: nist.gov X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6GF2VRc028551 P.S. I'm assuming OMG isn't responsible for problems caused by use of non-formal documents/artifacts. Andrew, Perhaps I misread your previous mail, but since UML 2.5 isn't formally available yet, why would a 2.5.1 be needed to bring 2.5 Beta 2 documents/artifacts in line with FTF decisions? Conrad From: "Bock, Conrad" To: Andrew Watson CC: "uml2-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmrw5PagIb1SK3EukjBq1EUxQnZubDuSA///4/gCAAHGoAIABjhYA//+/1/GAAAEm2oAAHahfgAQbAgCAAWNVDIAAS+AAgAAIcACAAAtNgIAAOnOA///SnPcAALdkkAABiNwAAACpYRA= Date: Wed, 16 Jul 2014 16:03:23 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.32.106] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(199002)(189002)(106356001)(93886003)(64706001)(54356999)(76482001)(31966008)(87936001)(95666004)(85852003)(99286002)(4396001)(99396002)(83072002)(79102001)(106116001)(76176999)(105586002)(33646002)(110136001)(77982001)(50986999)(86362001)(81342001)(74316001)(85306003)(101416001)(74502001)(74662001)(77096002)(81542001)(107046002)(80022001)(20776003)(66066001)(83322001)(92566001)(2656002)(46102001)(76576001)(21056001)(108616002)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:DM2PR09MB0285;H:DM2PR09MB0285.namprd09.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;LANG:en; X-OriginatorOrg: nist.gov X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6GG3V89031860 Andrew, > For better or worse, we put RTF reports on the public specification > pages as soon as they're approved by the Board. But this isn't the same as formally available is it? That would require the spec to be in /formal and linked under a non-beta spec page, presumably. > These same URLs will be placed on the "formal" UML 2.5 download page > when its created. So these URL aren't formally available. > Anyone linking to them now will not necessarily notice when > the UML 2.5 Beta2 page goes away, and the UML 2.5 formal page appears. I would think OMG isn't responsible for what people do with the contents of these URLs before they're formally available. Conrad From: "Bock, Conrad" To: Andrew Watson CC: "uml2-rtf@omg.org" Subject: RE: UML 2.5 Beta 2 XMI invalid Thread-Topic: UML 2.5 Beta 2 XMI invalid Thread-Index: AQHPmrw5PagIb1SK3EukjBq1EUxQnZubDuSA///4/gCAAHGoAIABjhYA//+/1/GAAAEm2oAAHahfgAQbAgCAAWNVDIAAS+AAgAAIcACAAAtNgIAAOnOA///SnPcAALdkkAABiNwAAACpYRA= Date: Wed, 16 Jul 2014 16:16:08 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.32.106] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(199002)(189002)(77096002)(74662001)(107046002)(81542001)(85306003)(74316001)(74502001)(101416001)(76576001)(19580395003)(46102001)(21056001)(66066001)(83322001)(80022001)(20776003)(2656002)(92566001)(31966008)(87936001)(54356999)(15395725005)(76482001)(99286002)(95666004)(85852003)(106356001)(64706001)(93886003)(15202345003)(50986999)(86362001)(15975445006)(77982001)(81342001)(79102001)(83072002)(4396001)(99396002)(76176999)(105586002)(33646002)(106116001)(110136001)(108616002)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:DM2PR09MB0285;H:DM2PR09MB0285.namprd09.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;LANG:en; X-OriginatorOrg: nist.gov X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s6GGGGhL000430 P.S. The public would only know about the URLs from the UML spec page: http://omg.org/spec/UML which shows UML 2.5 as "adopted" (in quotes) separate from the the formally released versions. It links to a page that says "Beta" in bold letters at the top. This is generally interpreted as "use at your own risk". I think OMG isn't responsible for problems caused by clearly marked beta documents and artifacts. Conrad Andrew, > For better or worse, we put RTF reports on the public specification > pages as soon as they're approved by the Board. But this isn't the same as formally available is it? That would require the spec to be in /formal and linked under a non-beta spec page, presumably. > These same URLs will be placed on the "formal" UML 2.5 download page > when its created. So these URL aren't formally available. > Anyone linking to them now will not necessarily notice when > the UML 2.5 Beta2 page goes away, and the UML 2.5 formal page appears. I would think OMG isn't responsible for what people do with the contents of these URLs before they're formally available. Conrad