PLEASE PROOF: Draft COR Set 1 for 29500

[Francis Cave]

We cannot have decided something that is contrary to the JTC 1 Directives. If what you're saying was agreed (and I have absolutely no recollection of that - I may have been out of the room at the time), I believe that is contrary to the Directives. 

As a result of the BRM a final text was published, and we know that the final text fails to implement all the decisions of the BRM. If the final text does not implement a decision of the BRM, it is probably a defect - although not all decisions of the BRM were wise, so we know that it is also the case that some defects are the result of BRM decisions that WERE implemented. There are also, of course, other defects that have nothing to do with decisions the BRM did or did not make.

But the final text is what it is, and we agreed in Prague that we would decide whether to fix a defect in a COR or in an AMD according to several criteria, including whether or not the remedy breaks existing implementations. 

Consider the case of the namespace issue raised by the Swiss NB. Let us suppose that the BRM had agreed that S should be in a separate namespace to T, but this hadn't been implemented in the final text. Are you saying that we would in that case have chosen to fix this issue in a COR?

If we try to use a COR to make breaking changes to the standard as published (i.e. the final text), some NBs will view this as an abuse of process and will disapprove the COR, regardless of the merits what is proposed. They will simply see it as an attempt to push through major changes "on the nod".

Francis Cave



> -----Original Message-----
> From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk]
> Sent: 06 July 2009 08: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 €
> > >
> > >
> >