New Info: RE: vOTE CALL: RE: Counter Proposal Paper Draft 0.9

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

I just talked to Klaus regarding this.  We do not have until May.  In order
to meet the urgent "infrastructure" release requirements (formerly Geneva),
Klaus stated that the we need this to QRT no later than Monday AM!!!  This
puts a null and void on ALL the ad hoc discussion at this time.  The dates
that Tim from QRT put together are not correct, with no time to edit and
incorporate comments in time for the plenary.  Also, the comments from QRT
regarding merging the document, dropping UML etc, are not realistic as the
target audience for these documents are software developers not management
personnel.  and two types of software developers; coding registry clients
and coding RAs.

ULTIMATELY we do have until May, which is why we have a v2.0 release via an
iterative approach.  We can incorporate, refine, whatever it takes with
v2.0, but for a v1.0 release, we need this complete no later than SUNDAY
NIGHT for Monday morning submission of BOTH the RS and RIM specs.  They need
to go together.

Having stated that, 1) I recommend the submission of the documents in the
current state, and 2) that people take a bit of a breather and relax a bit
over this weekend.  

Bob if you disagree, the executive team needs to resolve the timelines.

Scott

-----Original Message-----
From: Bob Sutor [mailto:rss@sutor.com]
Sent: Friday, January 12, 2001 9:37 AM
To: ebxml-regrep@lists.ebxml.org
Subject: RE: vOTE CALL: RE: Counter Proposal Paper Draft 0.9


I encourage you all to take enough time to consider all proposals and come
to the best solution. We've got until May, afterall.

Bob Sutor, IBM
Vice-Chair, ebXML

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Friday, January 12, 2001 10: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.