DR 10-0001 - removal of leap year bug from strict (was RE: Detailed agenda for the 2010-04-22 teleconf)

Tue May 4 00:27:38 CEST 2010

Certainly option 3 is the simplest from a text management point of view. As
all the final text will need to be published as a COR or AMD, the edits need
to be against the base standard, not to the base plus the edits from another
DR.

Rex

> -----Original Message-----
> From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> Sent: Friday, April 30, 2010 9:50 PM
> To: SC 34 WG4
> Subject: RE: DR 10-0001 - removal of leap year bug from strict (was RE:
> Detailed agenda for the 2010-04-22 teleconf)
> 
> I spoke to Gareth on the phone about this, and we'd like some advice. I
> said in Stockholm that the various SpreadsheetML date DRs could be
> worked upon independently of one another, but I may have to retract
> that statement.
> 
> WG4 are currently working simultaneously on:
> 
> * Removing 8601 dates from transitional (DR 09-0275)
> * Removing the leap year bug from strict (DR 10-0001)
> * Profiling 8601 dates (project JTC 1.34.29500.04.02.00.01)
> 
> Unfortunately all of these involve complex edits made to the same
> sections of text and (as Gareth's changes to the document on this
> thread demonstrate) it is becoming difficult to track the work
> independently and we're increasingly opening the risk of mistakes when
> we eventually integrate these DRs into the standard. It's more than
> just a different word here and there - for example, some of these
> changes involve many edits to text which another change is removing
> entirely.
> 
> I'd like to propose that we do one of:
> 
> 1. Get full agreement on the content of each DR/project from WG4 before
> moving onto the next, and base the edits for each DR/project on the
> standard as it would look were the previous one accepted (if the
> previous one is rejected, we will then have to rewrite all the later
> ones)
> 2. Agree that each DR/project will be based upon the core standard and
> then, if they are accepted, rewrite the required changes to fit with
> the others
> 3. Combine the proposed changes for each DR/project into one single
> list of changes to the standard required to effect all of them
> 
> I would personally prefer the option 3 as I think it will be the
> easiest - in the case of both 1 and 2, the amount of rewriting required
> will be substantial. However, I'm new here and I'd appreciate any
> guidance anyone has.
> 
> Have a good weekend,
> 
> Chris
> 
> -----Original Message-----
> From: Horton, Gareth [mailto:Gareth_Horton at datawatch.com]
> Sent: 29 April 2010 10:16
> To: Chris Rae; Jesper Lund Stocholm; MURATA Makoto (FAMILY Given)
> Cc: SC 34 WG4
> Subject: RE: DR 10-0001 - removal of leap year bug from strict (was RE:
> Detailed agenda for the 2010-04-22 teleconf)
> 
> Hi all,
> 
> I have done some major surgery on this.  I gave up a little towards the
> end, as we need to discuss the fact that the "new" 1900 date system
> should be removed from Transitional, since we are removing ISO8601
> dates for interop purposes.  It follows that we need to remove the
> mechanism for creating non-interoperable dates.
> 
> I also feel it makes little sense to do the text changes on this DR
> without the ISO8601 profiling improvements and a general tightening of
> the text.
> 
> I have made some changes and comments in this respect for your
> feedback.
> 
> Thanks
> 
> Gareth
> 
> -----Original Message-----
> From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> Sent: 29 April 2010 17:21
> To: Jesper Lund Stocholm; MURATA Makoto (FAMILY Given); SC 34 WG4
> Subject: RE: DR 10-0001 - removal of leap year bug from strict (was RE:
> Detailed agenda for the 2010-04-22 teleconf)
> 
> I've accepted most of JLS' comments and put responses next to a couple.
> 
> One question: Can someone present at the BRM tell us whether the intent
> was to change the "1904 date base" to the "1904 backwards compatibility
> date base"? There seems to have been an effort to add text saying that
> the 1900 date base is the preferred date base, and renaming the 1904
> date base to make it a second-class citizen (along with the now
> moribund 1900 back-compat date base).
> 
> If I don't hear back from anyone who was at the BRM, I'm going to
> follow Jesper's suggestion and reinvest the 1904 date base with the
> glory it had back in ECMA 376.
> 
> Chris
> 
> -----Original Message-----
> From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk]
> Sent: 29 April 2010 01:16
> To: Chris Rae; MURATA Makoto (FAMILY Given); SC 34 WG4
> Subject: RE: DR 10-0001 - removal of leap year bug from strict (was RE:
> Detailed agenda for the 2010-04-22 teleconf)
> 
> Hi Chris (all),
> 
> Overall it looks good to me. I have made some comments inline.
> 
> 
> Jesper Lund Stocholm
> ciber Danmark A/S
> 
> > -----Original Message-----
> > From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> > Sent: 27. april 2010 22:07
> > To: Jesper Lund Stocholm; MURATA Makoto (FAMILY Given); SC 34 WG4
> > Subject: DR 10-0001 - removal of leap year bug from strict (was RE:
> > Detailed agenda for the 2010-04-22 teleconf)
> >
> > Okay, this turned out to be a lot more involved than I expected.
> > Changes are in the attached word document and PDF. A couple of
> points:
> >
> > * I left references to the "1904 backwards-compatibility date base"
> the
> > same (i.e. I did not remove "backwards-compatibility"). The work done
> > at the BRM appeared to be steering consumers away from both the leap-
> > year bug and the 1904 date base, so I didn't want to undo that.
> > * I am not 100% sure I've changed the schemas in the right way. I'd
> > appreciate a second pair of eyes.
> > * Unlike any other transitional features, this requires not just a
> > change in schema and normative schema element descriptions - it also
> > involves a large change some pieces of prose (sections that talk in
> > general terms about dates). I wondered about referring to ECMA-376
> here
> > but Murata-san preferred the idea of just pasting the prose into Part
> > 4, so I've done that. This prose will change when we integrate the
> ISO
> > 8601 profiling - we will have to remember to update these in the
> right
> > order (it should be apparent at the time as the section will have
> moved
> > to another Part).
> >
> > Your thoughts much appreciated,
> >
> > Chris
> >
> > -----Original Message-----
> > From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> > Sent: 23 April 2010 13:12
> > To: Jesper Lund Stocholm; MURATA Makoto (FAMILY Given); SC 34 WG4
> > Subject: RE: Detailed agenda for the 2010-04-22 teleconf
> >
> > I dropped the ball on this - will do it in the next few days so we'll
> > be fine to put it on the agenda for the next meeting.
> >
> > Chris
> >
> > -----Original Message-----
> > From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk]
> > Sent: 21 April 2010 01:10
> > To: MURATA Makoto (FAMILY Given); SC 34 WG4
> > Subject: RE: Detailed agenda for the 2010-04-22 teleconf
> >
> > Hello Murata-san,
> >
> > I see that "DR 10-0001,  SML: Removal of dateCompatibility attribute"
> > is on the agenda for tomorrow. As the minutes from last TC tell we
> > decided to remove the attribute for strict documents. But we have not
> > yet received a write-up from Chris, so I think it would be premature
> to
> > deal with this again at the TC tomorrow (which I am not able to
> attend,
> > btw).
> >
> > I propose we postpone this DR until we have some concrete wording to
> > look at.
> >
> >
> > Jesper Lund Stocholm
> > ciber Danmark A/S
> >
> > > -----Original Message-----
> > > From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-
> net.or.jp]
> > > Sent: 21. april 2010 06:54
> > > To: SC 34 WG4
> > > Subject: Detailed agenda for the 2010-04-22 teleconf
> > >
> > > Dear colleagues,
> > >
> > > The agenda has been published as SC34 N1417, but this detailed
> agenda
> > > shows which DR to be discussed.
> > >
> > >    1. Opening of the Meeting (14:00GMT)
> > >    2. Roll Call of Participants
> > >    3. Adoption of the Agenda
> > >    4. Approval of the Draft Minutes
> > >    5. Defect reports
> > >           * Custom XML DRs (DR 09-0207, DR 09-0208, DR 09-0210,
> > >                DR 09-0211, and DR 09-0213)
> > >                   Custom XML on 4/8 WG4 Meeting on 2010-03-29
> > >                   Custom XML Defect Reports Batch on 2010-03-24
> > >           * DR 09-0012, Parts, Font Part: Incomplete definition for
> > > Font Part
> > >           * DR-09-0030,  OPC: Placement of package
> > > RelationshipReference
> > >                                    elements
> > >           * DR 09-0157,  WML restriction on ordering of run
> > properties
> > >           * DR-09-0165,  SML and PML: Lack of Media Types
> > >           * DR 09-0168,  OPC: No mechanism to distinguish
> > ECMA-376:2006
> > >                                    from IS 29500
> > >           * DR-09-0216, WML: Custom XML and Smart Tags
> > >           * DR 10-0001,  SML: Removal of dateCompatibility
> attribute
> > >    7. Any Other Business
> > >           * Removing 8601 dates from Transitional
> > >           * Tentative COR/AMD assignments
> > >                   See Shawn's proposal, Proposal for Corrigenda vs.
> > >                   Amendment Bucketing for Stockholm Defect Reports,
> > on
> > >                   2010-03-22
> > >    8. Adjournment (16:00GMT)
> > >
> > >
> > > Regards,
> > >
> > >
> > > SC34/WG4 Convenor
> > > MURATA Makoto (FAMILY Given)
> >
> >