Re: vOTE CALL: RE: Counter Proposal Paper Draft 0.9

[duane <duane@xmlglobal.com>]

There is a way to do this (referring to below message).  There are a lot
of people following this thread who will eventually be voting on this
issue (as the plenary).  We have a vested interest in choosing the best
technical solution.  

Accordingly,  I would vote that the new document be considered.  It has
merits (speaking from an implementors POV).

I vote "YES"

Duane NIckull


> 
> There has to be a way of resolving all this and picking the best technical
> solution without getting personal or taking things personal.  It would just
> improve the atmosphere a bit and ease the tension, allowing everyone to
> focus on the technical merits of the proposals without being distracted by
> the slander.
> 
> Thanks,
> 
> Waqar Sadiq
> 
> 
> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Friday, January 12, 2001 9:29 AM
> To: Farrukh Najmi
> Cc: 'ebxml repository '
> Subject: Re: vOTE CALL: RE: Counter Proposal Paper Draft 0.9
> 
> Message text written by Farrukh Najmi
> >> I recommend a NO vote because:
> > - Its not obvious to my how this proposal is better than the existing
> > proposal (from a pros cons point of view).
> > - the state of this document needs work
> > - the estimated time to incorporate this document is great
> > - the "dynamics" of this project team reminds me of a bunch of old mules
> > that prevent us from agreeing on a quick path
> >
> > We'll have more time to talk later about this document, as I want more
> > information such as the origin etc.   I do see some interesting use
> cases,
> > but again, not enough time.
> <<<<<<<<<<<<<<<
> 
> Halleluh - what a surprise - and my prediction hath come to pass.
> 
> Privately I made the prediction on Monday that - once I had busted my chops
> this week and hustled on all this - the final analysis from the Sun bastion
> 
> would be - we have not had enough time, there is not enough time, there's
> not been enough time spent on this.  Frankly this is a tired and broken
> record.
> 
> Let's see now - 20 odd methods - 5 odd people, 4 a piece.   If we focus in
> on REALLY getting an abstraction layer API built here - it is possible.
> 
> However - at the start of the week I had plenty of specific detail
> 'Oh - you're inventing your own scripting process / query syntax",
> now I've attempt to listen to that by allowing implementors to
> specify that in a programming tool of their choice
> 'Oh - its too vague, it does not give specifics'.
> 
> Ok - well the bottom line for me is that OQL query statements is
> something no DBA worth their salt would allow against a
> backend server over an open channel.  So what's it to be?
> 
> I can add more specifics back in - but then I am I going to hear
> shouts of 'foul' again?
> 
> Someone else can run round the track, work up a sweat, be
> pelted with rocks, and then told to run round the opposite
> way this time.
> 
> Thanks, DW.