RE: Send me Your Lists, Yearning to Breath Free ...

Sure.  Here's the rough format I used.

1. The name and 1 sentence summary of the functional area is listed first.
2. Each "grouping" of working that has been proposed by an interested party
listed.  The name of a committee, URI, name of spec, URI, status in any
standards body listed.

I objected to
- terms like "competing", saying something is "called".
- the subjective bias towards something being in a standards body.
- The comparison.  I have serious technical disagreements with the
referenced comparison work.  I had given this feedback to the author well
before the article was published btw.

Please note that I did take the moral high ground and I didn't start
slagging competitive works either on technical, process or marketing
grounds.  There are many many areas that we could get into doing the
mudslinging (say comparing the web services vendors % market share that have
announced support for each spec?? cough ).  I think any list needs to report
facts in as unbiased a manner as possible without the slightest bit of bias.
Frankly, I like the Robin Cover style of summarizing.  But that's if you
will allow our group to even talk about these work

Let me turn the question around Jeff.  Is Oracle comfortable or not
comfortable with listing works that BEA is involved in?  I don't think
you've really answered that.  I've heard some pushback about "proprietary"
specs, but not whether specs that you call proprietary must be excluded from
a ws-arch document.

Cheers,
Dave

> I'd be interested in the reasoning behind characterizing a reasonably
> objective and impartial summary of the situation as "unfair".
>
> >So I'd make your summary into something like:
> >
> >Reliable Messaging: A protocol that allows messages to be
> delivered reliably
> >between distributed applications in the presence of software
> component,
> >system, or network failures by implementing an acknowledgement
> >infrastructure.
> >Individual specifications and committees
> >- Web Services Reliability
> >http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm
> ><http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=w
> srm>  OASIS TC.
> >Based on WS-Reliability submission from Oracle, Sun and others (
> >http://otn.oracle.com/tech/webservices/htdocs/spec/ws-reliabi
> lity.html
> ><http://otn.oracle.com/tech/webservices/htdocs/spec/ws-reliab
> ility.html> )
> >- WS-ReliableMessaging (
> >http://msdn.microsoft.com/webservices/default.aspx?pull=/libr
> ary/en-us/dnglo
> >bspec/html/ws-reliablemessaging.asp
> ><http://msdn.microsoft.com/webservices/default.aspx?pull=/lib
> rary/en-us/dngl
> >obspec/html/ws-reliablemessaging.asp> ) from BEA Systems,
> Microsoft, IBM,
> >Tibco.   Not currently being worked on in a typical standards body.
>
> or any non-typical one.
>
> As much as some of us might like to wish otherwise, until
> specifications
> are submitted to standards bodies (or otherwise made freely
> available via
> explicit licensing terms), they are proprietary.
>
> cheers,
>    jeff
>
> >
> >Cheers,
> >Dave
> >
> >
> >-----Original Message-----
> >From: www-ws-arch-request@w3.org
> [mailto:www-ws-arch-request@w3.org]On
> >Behalf Of Cutler, Roger (RogerCutler)
> >Sent: Friday, September 12, 2003 7:46 AM
> >To: www-ws-arch@w3.org
> >Subject: RE: Send me Your Lists, Yearning to Breath Free ...
> >
> >
> >I got a couple responses to this that indicate I was utterly
> unclear in what
> >I am suggesting.  Sorry -- I think I was basing this too
> much on context
> >established in the telcon, some of it off-line.  Let me try again.
> >
> >It was suggested on the telcon that the WG develop a list of
> standards
> >efforts related to Web services.  One comment about the
> suggestion was to
> >question whether anyone was willing to do the work.  I am sort of
> >volunteering to do the following:
> >
> >All of us seem to have made such lists for internal use, but
> many seem to
> >view at least aspects of this work as confidential.  On the
> other hand, the
> >landscape is complex and we could all probably benefit from
> combining our
> >knowledge.  I know that I certainly would.  So I am sort of
> proposing an,
> >"I'll show you mine if you show me yours".  More
> specifically, if people
> >send me their lists of standards efforts, suitably edited if
> you like to
> >remove sensitive information, I will commit to do the
> following (if I am
> >able -- I say this in case I get input expressed in a way
> that I can't
> >figure out how to handle):
> >
> >1 - Combine them in such a way that individual authorship is
> more or less
> >disguised.
> >
> >2 - Remove any statements that seem unwise to make public.
> For example, if
> >I get, "That spec mostly comes from IBM and they're all
> clueless doofuses
> >there", I will chuckle privately but it ain't gonna get through.
> >
> >3 - Circulate the combined product to the contributors for
> comment before
> >making public.
> >
> >4 - Keep the original submissions private.
> >
> >5 - Respect requests NOT to use a submission unless there
> are a critical
> >number, Nc, of submissions.  I suggest Nc=3 might be reasonable.
> >
> >6 - Use my own list (which is not all that great) as one of
> the submissions.
> >
> >Note that the commitment to confidentiality applies within
> my company,
> >subject to the following:
> >
> >A - If push comes to shove I'm not sure I can withhold
> information from my
> >employer that I develop on their time.  I can't imagine,
> however, how this
> >would become relevant.  I'm certainly not going to handle anything
> >confidential inside CVX in a way that would be likely to leak out.
> >
> >B - If under 5 above I get a submission I can't use, of
> course if I learn
> >something from it I ain't gonna try to forget it.
> >
> >To be more specific about what submissions might look at,
> here is an entry
> >from my list about reliable messaging (which seems to be the
> example we keep
> >using).  Note that it contains URL's, a brief summary of
> what it's about,
> >and some comments about relative maturity and relationship
> to other specs.
> >(I'm not sure if the URL's are going to come through
> properly to the mailing
> >list, but in the version I have copied below the URL's are links).
> >
> ><example>
> >Web Services Reliable Messaging
> >http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm
> ><http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=w
srm> .  A
>protocol that allows messages to be delivered reliably between distributed
>applications in the presence of software component, system, or network
>failures by implementing an acknowledgement infrastructure.  Based on
>WS-Reliability submission from Oracle, Sun and others (
>http://otn.oracle.com/tech/webservices/htdocs/spec/ws-reliability.html
><http://otn.oracle.com/tech/webservices/htdocs/spec/ws-reliability.html> )
>A competing spec called WS-ReliableMessaging (
>http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dngl
o
>bspec/html/ws-reliablemessaging.asp
><http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dng
l
>obspec/html/ws-reliablemessaging.asp> ) from Microsoft, IBM, BEA and others
>has not yet been submitted to any organization.   The two specs are, in
>substance, pretty similar (
>http://xml.coverpages.org/ChappellReliability20030313.html
><http://xml.coverpages.org/ChappellReliability20030313.html> )
></example>
>

Received on Monday, 15 September 2003 14:05:25 UTC