PLEASE PROOF: Draft COR Set 1 for 29500

[Francis Cave]

Please give me a document reference to where we record agreement of point 1. If there is no documentary evidence of this decision - which in any case I think would be questionable in terms of the JTC 1 Directives - I doubt that such a decision was actually taken.

Francis




> -----Original Message-----
> From: Kimmo Bergius [mailto:Kimmo.Bergius at microsoft.com]
> Sent: 06 July 2009 09:49
> To: Jesper Lund Stocholm; francis at franciscave.com; Rex Jaeschke; SC 34
> WG4
> Subject: RE: PLEASE PROOF: Draft COR Set 1 for 29500
> 
> I agree with Jesper. Just to be clear, we have decided on two different
> issues:
> 1. If WG4 would receive a DR referring to a change that was agreed at
> the BRM, but that was not implemented fully in the text, then this
> would be changed and the change would be incorporated into COR,
> regardless of the implications of such a change to the text (an example
> of this is the percentage issue we have discussed for quite a while). I
> do not, however, remember whether this decision was reached in Okinawa
> or in Prague - but we did discuss it already in Okinawa.
> 2. If WG4 would decide to change a decision made by the BRM (an example
> of this would be the On/Off issue), then that change would
> automatically go into AMD. This was part of the principles that Francis
> and Shawn drafted.
> 
> Cheers,
> Kimmo
> 
> -----Original Message-----
> From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk]
> Sent: 6. heinäkuuta 2009 10:20
> To: francis at franciscave.com; Rex Jaeschke; SC 34 WG4
> Subject: RE: PLEASE PROOF: Draft COR Set 1 for 29500
> 
> Hello all,
> 
> Francis,
> 
> Even though I agree with your statements below, in Prague we decided to
> have a "prime directive" saying that if any changes from the BRM were
> not yet in the standard, correcting this would be an editorial fix and
> should therefore go in a COR. Whether this fix would break existing
> implementations were _not_ on the table.
> 
> I believe the reason was, that IS29500 now formally consists of the
> original submission by ECMA + the changes from the BRM. So if some of
> the BRM decisions had not made it in the final text, fixing this was
> purely editorial.
> 
> Jesper Lund Stocholm
> ciber Danmark A/S
> 
> 
> > -----Original Message-----
> > From: Francis Cave [mailto:francis at franciscave.com]
> > Sent: Friday, July 03, 2009 8:02 PM
> > To: 'Rex Jaeschke'; 'SC 34 WG4'
> > Subject: RE: PLEASE PROOF: Draft COR Set 1 for 29500
> >
> > No, that is not what WG4 decided in Prague and presented to SC34.
> >
> > JTC 1 rules say that if a change fixes something that is
> > unimplementable - e.g. inconsistencies in normative text - that can
> and
> > should be fixed in a COR. The document that we spent considerable
> time
> > on in Prague sets out the conditions under which a change that
> DOESN'T
> > fix something that is already broken can be in a COR rather than in
> an
> > AMD. If such a change can theoretically break existing
> implementations,
> > the change should be in an AMD, not in a COR.
> >
> > As I understand it, EDITORIAL changes that don't define new features
> or
> > change existing features can and should be in a COR.
> >
> > Francis Cave
> >
> >
> >
> > > -----Original Message-----
> > > From: Rex Jaeschke [mailto:rex at RexJaeschke.com]
> > > Sent: 03 July 2009 18:45
> > > To: 'SC 34 WG4'
> > > Subject: RE: PLEASE PROOF: Draft COR Set 1 for 29500
> > >
> > > I believe WG4 decided that any DR that raised issues that were
> > supposed
> > > to be implemented as a result of the BRM, but which were not, were
> > > assigned to a COR.
> > >
> > > Rex
> > >
> > >
> > > > -----Original Message-----
> > > > From: Innovimax SARL [mailto:innovimax at gmail.com]
> > > > Sent: Friday, July 03, 2009 1:23 PM
> > > > To: Rex Jaeschke
> > > > Cc: SC 34 WG4
> > > > Subject: Re: PLEASE PROOF: Draft COR Set 1 for 29500
> > > >
> > > > Thanks Rex !
> > > >
> > > > I'm suprised that all the Percentage Related stuff are in the COR
> > > >
> > > > My understanding was that all that makes EXISTING document
> invalid
> > > goes
> > > > to AMD
> > > >
> > > > Why are those one gone to COR ?
> > > >
> > > > Mohamed
> > > >
> > > > On Fri, Jul 3, 2009 at 1:29 PM, Rex Jaeschke<rex at rexjaeschke.com>
> > > > wrote:
> > > > > Attached are the 4 Draft Technical Corrigenda, more than a week
> > > ahead
> > > > of
> > > > > schedule. Please proof them and send any comments to this email
> > > list
> > > > as soon
> > > > > as possible. The plan is to review and, hopefully, close-out
> and
> > > > approve
> > > > > these on the phone call of July 23.
> > > > >
> > > > > These are complete with the exception of 2 DRs, 09-0157 and 09-
> > > 0216.
> > > > The
> > > > > debate on these 2 DRs can continue on the email list, and we
> can
> > > > close them
> > > > > on the phone call.
> > > > >
> > > > > Note that the non-trivial changes to the Relax NG schema are
> NOT
> > > > included.
> > > > > As we agreed, they will come later.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Rex
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Innovimax SARL
> > > > Consulting, Training & XML Development
> > > > 9, impasse des Orteaux
> > > > 75020 Paris
> > > > Tel : +33 9 52 475787
> > > > Fax : +33 1 4356 1746
> > > > http://www.innovimax.fr
> > > > RCS Paris 488.018.631
> > > > SARL au capital de 10.000 €
> > >
> > >
> >