> stretch this out for another week is up to you Gak! I don't want to do that. The ambiguity is the kind that crops up very frequently. I only wanted to flag it as the kind of issue that sometimes goes unnoticed and unattended, and later becomes very costly to repair. My recommendation is to just publish the CSD as we have it, and in the next spec rev, the TC can take up the ambiguity to resolve it formally. There is no real mechanism in the rules for debate and decision at this time (formally). I was looking for a hint because there are multiple creative ways to handle ambiguity that's inherent at predictable junctures. Any objections to just moving forward with the above understanding that it will get resolved later? There's been no PR requested for CSD02, so you can easily handle this in the CSD03 if that's next up. To repeat myself:
> Hear me: this case is not a big deal. -Cheers, -rcc Robin Cover Interim TC Administrator OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink
Email:
Staff bio: http://www.oasis-open.org/who/staff.php#cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783
On Wed, 16 Feb 2011, Toby Considine wrote:
> 1) I acknowledge neither one was named in the roll call vote.
> 2) TimeStamp is a throw-away. We made it, we're done with it, in
> conversations it is assumed. The TC has not spent any bandwidth on it since
> the initial production. We were asked to do it by parts of the national
> smart grid process. It is not part of the service interactions we are
> defining elsewhere. You can delete it or publish it as you please. As I
> have stated repeatedly, it is a side issue. If you doubt that, you can ask
> the TC.
> 3) You as TC Admin may declare whatever you want. If you want to say that
> you want another roll call vote two weeks after first because you finally
> notice, that is your right. It will be my right to complain.
> 4) The components that are included in ws-calendar.xsd are all in
> iCalendar-wscal-extensions.xsd. If you think I am not representing the sense
> of the TC accurately, well, we can ask them. If you think it is useful to
> have non-consensus non-standard alternate schemas on the OASIS site in
> perpetuity, go for it. >
> The relevant issue is, as *you* highlight, ** the constituent parts cannot
> advance independently of each other or stand on their own**. The ambiguity
> is that TimeStamp was not explicitly included in the zipped file that I
> sent. To be consistent and punctilious, you should include both or exclude
> both. Including both is clearly more harmful. Excluding both is a better fit
> with the process as outline below, but if that is the intent, I am not sure
> why you keep coming back to try to include them. >
> Whether you want to stretch this out for another week is up to you. I invite
> anyone on the TC who is feeling misused by my "misrepresentations" to chime
> in. >
> tc > > "If something is not worth doing, it`s not worth doing well" - Peter Drucker >
> Toby Considine
> TC9, Inc
> TC Chair: oBIX & WS-Calendar
> TC Editor: EMIX, EnergyInterop
> U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee > >
>
Email:
>
Phone: (919)619-2104
> http://www.tcnine.com/
> blog: www.NewDaedalus.com > > > >
