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'm looking to make sure ebXML moves ahead properly with appropriate review
of all reasonable solutions. Moreover, a JSR that  has 2/3 of its
contributions based on the ebXML registry and repository work is
extraordinarily appropriate for discussion on this list. I'm pleased to see
that most people here support that work as it is directly relevant to how
ebXML will play out in the marketplace.

Language bindings is not a red herring since it, once again, affects how
people will really use this stuff in practice. If there was a strong
sentiment that they should be developed here and not elsewhere, then that is
a matter for how ebXML is managed and how we might have to deal with, say,
open source licenses. Since we now seem to be close to having a real spec,
it is appropriate to revisit the issue. It was something that we discussed
quite a bit when we started this whole thing.

Bob Sutor, IBM
ebXML Vice-Chair


-----Original Message-----
From: Nicholas Kassem [mailto:Nick.Kassem@eng.sun.com]
Sent: Friday, January 12, 2001 1:46 PM
To: Bob Sutor; ebxml-regrep@lists.ebxml.org
Subject: RE: vOTE CALL: RE: Counter Proposal Paper Draft 0.9


Interesting comment Bob. Perhaps you could help me and others on this list
understand in what way did your informal language binding "survey" help in
calming the waters. I think having language binding discussions in this WG
is a red herring.

I'm all for taking a sensible and studious approach here but we don't need
apples-to-oranges pseudo technical comparisons. We should table technical
proposals, and back them up with sensible arguments and discuss the merits
in a collegial manner. In going through the most recent archives, seems to
me, we need to diffuse the situation so we can get back to sound technical
discourse. Do we really have until May to deal with all this stuff ? When I
last checked the ebXML project plans I didn't get that impression but
perhaps I'm missing something.

Regards,
Nick

At 10:37 AM 1/12/2001 -0500, Bob Sutor wrote:
>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.



[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