OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

I vote YES.

Matthew MacKenzie
VP Research & Development
XML Global Technologies, Inc. 

-----Original Message-----
From: Bob Sutor [mailto:rss@sutor.com]
Sent: January 12, 2001 7: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
> 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

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.
FN:Matthew MacKenzie
ORG:XML Global Technologies, Inc.;Research & Development
TITLE:VP Research & Development
TEL;WORK;VOICE:(604) 717-1100
TEL;VOICE:(800) 201-1848
TEL;WORK;FAX:(604) 717-1107
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;1818 Cornwall Avenue=0D=0ASuite 9;Vancouver;British Columbia;V6J 1C7;Canad=
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1818 Cornwall Avenue=0D=0ASuite 9=0D=0AVancouver, British Columbia V6J 1C7=

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC