PLEASE PROOF: Draft COR Set 1 for 29500

[Kimmo Bergius]

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 €
> >
> >
>