RFD: comp.protocols.soap
Dan Kegel
unmoderated group comp.protocols.soap
This is a formal Request For Discussion (RFD) for the creation of
world-wide unmoderated Usenet newsgroup comp.protocols.soap.
This is not a Call for Votes (CFV); you cannot vote at this time.
Procedural details are below.
Newsgroups line: comp.protocols.soap W3C's Simple Object Access Protocol
RATIONALE: comp.protocols.soap
The W3C's SOAP (Simple Object Access Protocol, see
<http://www.w3.org/TR/SOAP/> and the related concept xml-rpc) appears to
be an important standard for open distributed systems. Microsoft, IBM,
Sun, Apache, and scores of other vendors support SOAP. SOAP bindings
exist for Java, C++, Visual Basic, Delphi, Ada, Python, Perl, Ruby, PHP,
Flash, and many other programming languages. Bridges exist between SOAP
and CORBA.
More and more SOAP-related postings are appearing on Usenet. A search for
"soap group:comp.*, OR group:microsoft.*, OR group:borland.*" on
groups.google.com during November 2001 found an average of 32 postings per
day related to soap. However, due to the lack of a SOAP newsgroup, the
discussion is scattered over several newsgroups:
microsoft.public.xml.soap
comp.text.xml
comp.object.corba
comp.lang.java.programmer
borland.public.delphi.webservices.soap
and as many mailing lists. None of the newsgroups are devoted to
non-vendor-specific discussions about SOAP.
An increasing number of people expect to be able to use popular search
engines such as http://groups.google.com to find discussions about
important topics like SOAP. The fact that the main forums for
non-vendor-specific discussions about SOAP are mailing lists not indexed
by popular search engines renders these discussions hard to access for
such people. The purpose of the SOAP Usenet group is to make discussions
on the topic more accessible to the entire network community.
CHARTER: comp.protocols.soap
comp.protocols.soap is an unmoderated newsgroup for discussions about the
W3C's SOAP (Simple Object Access Protocol, defined at
http://www.w3.org/TR/SOAP/ ), particular implementations of SOAP, and how
to use them.
Possible discussion issues include:
- SOAP questions
- SOAP experience reports
- SOAP product evaluations
- SOAP component-ware
- Cross-Platform Development with SOAP
- Announcement of new SOAP documents
- Determining SOAP interfaces for commonly needed services
- Language support for SOAP
- SOAP web services
- Integration of legacy information systems into SOAP applications
- SOAP frameworks
- The future of SOAP
- SOAP seminar announcements
- SOAP books
- WSDL/UDDI
- Interoperability of SOAP with other standards, e.g. CORBA
The primary language of comp.protocols.soap is english; posting in other
languages is also permitted.
Flame wars, bad language, ad hominem arguments, and HTML posts are
strongly discouraged.
Limited posting of advertisements of SOAP products or services is
acceptable -- one advertisement per company per month, preferably very
brief, consisting mainly of a short blurb and a link to a website for
further info.
Commercial advertising unrelated to SOAP, binaries, and uuencoded posts
are prohibited.
END CHARTER.
PROCEDURE:
This is a request for discussion, not a call for votes. In this phase of
the process, any potential problems with the proposed newsgroup should be
raised and resolved. The discussion period will continue for a minimum of
21 days (starting from when the first RFD for this proposal is posted to
news.announce.newgroups), after which a Call For Votes (CFV) will be
posted by a neutral vote taker. Please do not attempt to vote until this
happens.
All discussion of this proposal should be posted to news.groups.
This RFD attempts to comply fully with the Usenet newsgroup creation
guidelines outlined in "How to Create a New Usenet Newsgroup" and "How to
Format and Submit a New Group Proposal". Please refer to these documents
(available in news.announce.newgroups) if you have any questions about the
process.
DISTRIBUTION:
This RFD has been posted to the following newsgroups:
news.announce.newgroups
news.groups
comp.text.xml
comp.object.corba
comp.protocols.misc
Pointers to the RFD will be posted to these groups:
comp.client-server
comp.lang.c++
comp.lang.java.programmer
comp.lang.perl.announce
comp.lang.python
comp.lang.ruby
news://news.microsoft.com/microsoft.public.xml.soap
news://newsgroups.borland.com/borland.public.delphi.webservices.soap
news://news.devx.com/xml.general
and to the following mailing list:
<so...@discuss.develop.com>
Proponent: Dan Kegel <da...@kegel.com>
Proponent: Randy Charles Morin <ra...@kbcafe.com>
Panu Viljamaa
But shouldn't it rather be called:
comp.protocols.webservices,
since WSDL and UDDI are clearly not part of SOAP,
but protocols in their own right ? And doubtless there'll
be more related acronyms upcoming.
-Panu Viljamaa
Dan Kegel
>
> Something like this would interest me.
> But shouldn't it rather be called:
>
> comp.protocols.webservices,
>
> since WSDL and UDDI are clearly not part of SOAP,
> but protocols in their own right ? And doubtless there'll
> be more related acronyms upcoming.
Widening the name isn't a bad idea, but I'm not sure comp.protocols
would then be the right home for it, as e.g. WSDL isn't a protocol.
Suggestions welcome.
Looks like there are Microsoft-specific newsgroups named
microsoft.public.webservices.* that ought to be added to
the RFD.
FWIW, WSDL leans on SOAP even for the other bindings; see section
2.2 of http://www.w3.org/TR/wsdl , so there is a fig leaf
to cover us if we decide to keep the comp.*.soap name, maybe.
I don't know what to make of UDDI yet, but it certainly deserves
mention in the RFD as a related proposed standard. Microsoft
also has a UDDI newsgroup set, microsoft.public.uddi.*.
- Dan
ru.ig...@usask.ca
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.protocols.soap
I think I see why Pannu commented on the name. If this did belong
to the c.protocols hierarchy, why isn't there more discussion of
SOAP there? Or another way of looking at it, what topic space
does SOAP most closely resemble? It's tied to XML, so why not
in the same hierarchy as XML discussions, or the other server
("server" isn't what I intend, but my vocab just locked up)
based groups like the ones for Java or Perl? Comp.protocols
looks more like a low level protocol hierarchy. SOAP looks
like something that works at a higher level, sort of like a
layer on HTML and other languages. Does SOAP really fit in
c.protocols?
If there is no similar group, why not create one for this
type of protocol and include the ones that would otherwise
be excluded.
Then there is the issue of acronyms. You can get away with
it in c.protocols, since that's just about all there is in
that hierarchy. But it might not be so appropriate in
other hierarchies. Apart from a more general name (for
a more general group), are there alternatives to using
an acronym?
Apart from that, nothing else seems to stand out as problematic
in the proposal.
Well... I see you have limited the primary distribution to 5 groups.
I assume that is to get around the G5 filtering problem. You
might want to check the comp.* groups in that list to see if
if the RFD didn't show up for some people (how many, and what
ISP). I always wonder if G5 means kill if number of groups
is greater than or equal to 5, or just greater than 5.
ru
---
My (updated) standard proposals rant:
Quality, usefulness, merit, or non-newsgroups popularity of a topic
is more or less irrelevant in creating a new Big-8 newsgroup.
Usenet popularity is the primary consideration.
Russ Allbery
> I think I see why Pannu commented on the name. If this did belong to
> the c.protocols hierarchy, why isn't there more discussion of SOAP
> there?
comp.protocols.* isn't that sort of hierarchy. Generally protocol
discussion starts in random groups about software or computer systems
where the protocol is used. A group for miscellaneous discussion of
protocols makes no real sense and wouldn't be useful.
Suppose comp.protocols.time.ntp didn't exist, for example. The discussion
would likely be scattered mostly through comp.sys.* and comp.os.* where
people were trying to keep their systems in sync with the current time
until a protocols group was created.
comp.protocols.misc would cover so much ground that it would be
essentially useless, just like the main IETF list is.
> Or another way of looking at it, what topic space does SOAP most closely
> resemble? It's tied to XML,
So's every other modern data interchange protocol, practically. They
don't fit into comp.text.*, which is where XML schemas are primarily
discussed.
> so why not in the same hierarchy as XML discussions, or the other server
> ("server" isn't what I intend, but my vocab just locked up) based groups
> like the ones for Java or Perl?
Java and Perl are programming languages and SOAP isn't. They don't fit
into the same topic space at all.
> Comp.protocols looks more like a low level protocol hierarchy. SOAP
> looks like something that works at a higher level, sort of like a layer
> on HTML and other languages. Does SOAP really fit in c.protocols?
I think it does. It's no more high-level than SNMP is.
> If there is no similar group, why not create one for this type of
> protocol and include the ones that would otherwise be excluded.
This argument I can see to a degree; comp.protocols.rpc may not be a bad
idea. The problem is that the immediate assumption would be that it was
for the standard RPC protocol rather than the more general family of RPC
protocols (which include SOAP and XML-RPC), and I doubt people talking
about SOAP would find it.
And while SOAP is a remote procedure call protocol, I've not seen RPC
mentioned in the same context all that much except when people are trying
hard to classify things.
> Then there is the issue of acronyms. You can get away with it in
> c.protocols, since that's just about all there is in that hierarchy.
> But it might not be so appropriate in other hierarchies. Apart from a
> more general name (for a more general group), are there alternatives to
> using an acronym?
No, really, there pretty much aren't, at least that I can think of.
I'm pretty happy with the group name as proposed. Given what I know of
SOAP (we use some applications based on it here at Stanford), it seems
pretty well placed to me I'm not sure anything would be gained from trying
to put more hierarchy on it. I guess one of the other possibilities would
be to try to come up with a comp.protocols.rpc.* hierarchy of some sort,
but that name is rather problematic.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Dan Kegel
> > If there is no similar group, why not create one for this type of
> > protocol and include the ones that would otherwise be excluded.
>
> This argument I can see to a degree; comp.protocols.rpc may not be a bad
> idea. The problem is that the immediate assumption would be that it was
> for the standard RPC protocol rather than the more general family of RPC
> protocols (which include SOAP and XML-RPC), and I doubt people talking
> about SOAP would find it.
>
> And while SOAP is a remote procedure call protocol, I've not seen RPC
> mentioned in the same context all that much except when people are trying
> hard to classify things.
> be to try to come up with a comp.protocols.rpc.* hierarchy of some sort,
> but that name is rather problematic.
It's worth discussing, though. Maybe it's not as confusing now as in
onc-rpc's heyday, before other rpc's sprang up.
Has anyone done a taxonomy showing the things that are derived in
some way from rpc? Corba might fit in there, too, somehow.
Also, the whole rpc area seems important enough that it's tempting to
think of hoisting it up a level, e.g. comp.rpc.*
- Dan
Panu Viljamaa
But shouldn't it rather be called:
comp.protocols.webservices,
since WSDL and UDDI are clearly not part of SOAP,
but protocols in their own right ? And doubtless there'll
be more related acronyms upcoming.
-Panu Viljamaa
Dan Kegel wrote:
========= WAS CANCELLED BY =======:
Message-ID: <cancel.3C0EE...@fcc.net>
Control: cancel <3C0EEB69...@fcc.net>
Subject: cmsg cancel <3C0EEB69...@fcc.net>
From: Panu Viljamaa <pa...@fcc.net>
Date: Thu, 6 Dec 2001 16:45:23 GMT
X-No-Archive: yes
Newsgroups: microsoft.test,comp.lang.c,news.groups
NNTP-Posting-Host: mail.jbcharles.com 63.227.23.121
Lines: 1
Path: news.uni-stuttgart.de!dns.phoenix-ag.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.media.kyoto-u.ac.jp!news-feeds.jump.net!dfw-peer.news.verio.net!sea-feed.news.verio.net!news.verio.net!msrnewsc1!cppssbbsa01.microsoft.com!tkmsftngp01!tkmsftngp07!unacanceller
Xref: news.uni-stuttgart.de control:39747757
autocancel
Dan Kegel
> > If there is no similar group, why not create one for this type of
> > protocol and include the ones that would otherwise be excluded.
>
> This argument I can see to a degree; comp.protocols.rpc may not be a bad
> idea. The problem is that the immediate assumption would be that it was
> for the standard RPC protocol rather than the more general family of RPC
> protocols (which include SOAP and XML-RPC), and I doubt people talking
> about SOAP would find it.
>
> And while SOAP is a remote procedure call protocol, I've not seen RPC
> mentioned in the same context all that much except when people are trying
> hard to classify things.
> be to try to come up with a comp.protocols.rpc.* hierarchy of some sort,
> but that name is rather problematic.
It's worth discussing, though. Maybe it's not as confusing now as in
onc-rpc's heyday, before other rpc's sprang up.
Has anyone done a taxonomy showing the things that are derived in
some way from rpc? Corba might fit in there, too, somehow.
Also, the whole rpc area seems important enough that it's tempting to
think of hoisting it up a level, e.g. comp.rpc.*
- Dan
========= WAS CANCELLED BY =======:
Message-ID: <cancel.3C0FA...@kegel.com>
Control: cancel <3C0FABF4...@kegel.com>
Subject: cmsg cancel <3C0FABF4...@kegel.com>
From: Dan Kegel <da...@kegel.com>
Date: Thu, 6 Dec 2001 19:27:05 GMT
X-No-Archive: yes
Newsgroups: microsoft.test,comp.lang.c,news.groups
NNTP-Posting-Host: mail.jbcharles.com 63.227.23.121
Lines: 1
Path: news.uni-stuttgart.de!dns.phoenix-ag.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.media.kyoto-u.ac.jp!out.nntp.be!propagator-SanJose!in.nntp.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!sjc-peer.news.verio.net!sea-feed.news.verio.net!news.verio.net!msrnewsc1!cppssbbsa01.microsoft.com!tkmsftngp01!tkmsftngp07!unacanceller
Xref: news.uni-stuttgart.de control:39747729
autocancel
ru.ig...@usask.ca
> unmoderated group comp.protocols.soap
I think I see why Pannu commented on the name. If this did belong
to the c.protocols hierarchy, why isn't there more discussion of
SOAP there? Or another way of looking at it, what topic space
does SOAP most closely resemble? It's tied to XML, so why not
in the same hierarchy as XML discussions, or the other server
("server" isn't what I intend, but my vocab just locked up)
based groups like the ones for Java or Perl? Comp.protocols
looks more like a low level protocol hierarchy. SOAP looks
like something that works at a higher level, sort of like a
layer on HTML and other languages. Does SOAP really fit in
c.protocols?
If there is no similar group, why not create one for this
type of protocol and include the ones that would otherwise
be excluded.
Then there is the issue of acronyms. You can get away with
it in c.protocols, since that's just about all there is in
that hierarchy. But it might not be so appropriate in
other hierarchies. Apart from a more general name (for
a more general group), are there alternatives to using
an acronym?
Apart from that, nothing else seems to stand out as problematic
in the proposal.
Well... I see you have limited the primary distribution to 5 groups.
I assume that is to get around the G5 filtering problem. You
might want to check the comp.* groups in that list to see if
if the RFD didn't show up for some people (how many, and what
ISP). I always wonder if G5 means kill if number of groups
is greater than or equal to 5, or just greater than 5.
ru
---
My (updated) standard proposals rant:
Quality, usefulness, merit, or non-newsgroups popularity of a topic
is more or less irrelevant in creating a new Big-8 newsgroup.
Usenet popularity is the primary consideration.
========= WAS CANCELLED BY =======:
Message-ID: <cancel.9un61p$ola$1...@tribune.usask.ca>
Control: cancel <9un61p$ola$1...@tribune.usask.ca>
Subject: cmsg cancel <9un61p$ola$1...@tribune.usask.ca>
From: ru.ig...@usask.ca
Date: Thu, 6 Dec 2001 19:23:52 GMT
X-No-Archive: yes
Newsgroups: microsoft.test,comp.lang.c,news.groups
NNTP-Posting-Host: mail.jbcharles.com 63.227.23.121
Lines: 1
Path: news.uni-stuttgart.de!dns.phoenix-ag.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.media.kyoto-u.ac.jp!news-feeds.jump.net!dfw-peer.news.verio.net!sea-feed.news.verio.net!news.verio.net!msrnewsc1!cppssbbsa01.microsoft.com!tkmsftngp01!tkmsftngp07!unacanceller
Xref: news.uni-stuttgart.de control:39747756
autocancel
Russ Allbery
> I think I see why Pannu commented on the name. If this did belong to
> the c.protocols hierarchy, why isn't there more discussion of SOAP
> there?
comp.protocols.* isn't that sort of hierarchy. Generally protocol
discussion starts in random groups about software or computer systems
where the protocol is used. A group for miscellaneous discussion of
protocols makes no real sense and wouldn't be useful.
Suppose comp.protocols.time.ntp didn't exist, for example. The discussion
would likely be scattered mostly through comp.sys.* and comp.os.* where
people were trying to keep their systems in sync with the current time
until a protocols group was created.
comp.protocols.misc would cover so much ground that it would be
essentially useless, just like the main IETF list is.
> Or another way of looking at it, what topic space does SOAP most closely
> resemble? It's tied to XML,
So's every other modern data interchange protocol, practically. They
don't fit into comp.text.*, which is where XML schemas are primarily
discussed.
> so why not in the same hierarchy as XML discussions, or the other server
> ("server" isn't what I intend, but my vocab just locked up) based groups
> like the ones for Java or Perl?
Java and Perl are programming languages and SOAP isn't. They don't fit
into the same topic space at all.
> Comp.protocols looks more like a low level protocol hierarchy. SOAP
> looks like something that works at a higher level, sort of like a layer
> on HTML and other languages. Does SOAP really fit in c.protocols?
I think it does. It's no more high-level than SNMP is.
> If there is no similar group, why not create one for this type of
> protocol and include the ones that would otherwise be excluded.
This argument I can see to a degree; comp.protocols.rpc may not be a bad
idea. The problem is that the immediate assumption would be that it was
for the standard RPC protocol rather than the more general family of RPC
protocols (which include SOAP and XML-RPC), and I doubt people talking
about SOAP would find it.
And while SOAP is a remote procedure call protocol, I've not seen RPC
mentioned in the same context all that much except when people are trying
hard to classify things.
> Then there is the issue of acronyms. You can get away with it in
> c.protocols, since that's just about all there is in that hierarchy.
> But it might not be so appropriate in other hierarchies. Apart from a
> more general name (for a more general group), are there alternatives to
> using an acronym?
No, really, there pretty much aren't, at least that I can think of.
I'm pretty happy with the group name as proposed. Given what I know of
SOAP (we use some applications based on it here at Stanford), it seems
pretty well placed to me I'm not sure anything would be gained from trying
to put more hierarchy on it. I guess one of the other possibilities would
be to try to come up with a comp.protocols.rpc.* hierarchy of some sort,
but that name is rather problematic.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
========= WAS CANCELLED BY =======:
Message-ID: <cancel.ylo...@windlord.stanford.edu>
Control: cancel <yloflck...@windlord.stanford.edu>
Subject: cmsg cancel <yloflck...@windlord.stanford.edu>
From: Russ Allbery <r...@stanford.edu>
Date: Thu, 6 Dec 2001 16:52:00 GMT
X-No-Archive: yes
Newsgroups: microsoft.test,comp.lang.c,news.groups
NNTP-Posting-Host: mail.jbcharles.com 63.227.23.121
Lines: 1
Path: news.uni-stuttgart.de!dns.phoenix-ag.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.media.kyoto-u.ac.jp!news-feeds.jump.net!dfw-peer.news.verio.net!sea-feed.news.verio.net!news.verio.net!msrnewsc1!cppssbbsa01.microsoft.com!tkmsftngp01!tkmsftngp07!unacanceller
Xref: news.uni-stuttgart.de control:39747754
autocancel
Randy Charles Morin
I got to thinking. SOAP isn't an RPC. It's not application layer protocol
like NTP or TCP-IP or SNMP either. SOAP over HTTP is an RPC and an
application layer protocol, but SOAP could run over any transport, SMTP,
TCP-IP, FTP, or whatever. It's only glued to HTTP, out of convenience.
So, I don't think there should be a SOAP newsgroup under "comp.protocols.*".
So what does SOAP compare too? It compares to HTML. SOAP is the machine
readable messaging standard, just as HTML is the humand readable messaging
standard.
So does it belong in "comp.infosystems.www.authoring.soap"? Doubt it. We
don't author SOAP. Machines author SOAP.
It also compares to WML and HDML, but they don't have specific newsgroups.
It also compares to VRML, which has a home at "comp.lang.vrml". So is SOAP a
language? Yes. It's an XML grammar and XML is a langage. So, maybe we should
be thinking "comp.lang.soap" instead.
With all that said. I'd be willing to eat these words if we could get the
soap
newsgroup up and running one day earlier.
--
Randy Charles Morin
Author of Programming Windows Services
http://www.kbcafe.com
Feel free to contact me by private email or messenger
MSN Messenger - morin...@hotmail.com
Yahoo Messenger - randy...@yahoo.com
Ask Randy Newsgroup - http://communities.msn.com/KBCafecom/askrandy.msnw
"Dan Kegel" <da...@kegel.com> wrote in message
news:10075053...@isc.org...
Dan Kegel
>
> With you all talking about "where SOAP belongs in the newsgroup hierarchy",
> I got to thinking. SOAP isn't an RPC. It's not application layer protocol
> like NTP or TCP-IP or SNMP either. SOAP over HTTP is an RPC and an
> application layer protocol, but SOAP could run over any transport, SMTP,
> TCP-IP, FTP, or whatever. It's only glued to HTTP, out of convenience.
>
> So, I don't think there should be a SOAP newsgroup under "comp.protocols.*".
> So what does SOAP compare too? It compares to HTML. SOAP is the machine
> readable messaging standard, just as HTML is the humand readable messaging
> standard.
Taxonomy is fun. I'm enjoying the insights.
> It also compares to WML and HDML, but they don't have specific newsgroups.
> It also compares to VRML, which has a home at "comp.lang.vrml". So is SOAP a
> language? Yes. It's an XML grammar and XML is a langage. So, maybe we should
> be thinking "comp.lang.soap" instead.
It's an RPC! It's a messaging system! It's a language!
(And, dare I say, it probably shines shoes nicely :-)
I dunno about the language part, since languages are arguably for humans;
when it's only for machines, people tend to call it a format or a code,
don't they?
Are there any newsgroups for message-oriented middleware per se? Google
shows comp.object.corba and comp.client-server being the most common
places that's mentioned. Hmm.
- Dan
Russ Allbery
> Randy Charles Morin wrote:
>> It also compares to WML and HDML, but they don't have specific
>> newsgroups. It also compares to VRML, which has a home at
>> "comp.lang.vrml". So is SOAP a language? Yes. It's an XML grammar and
>> XML is a langage. So, maybe we should be thinking "comp.lang.soap"
>> instead.
The comp.lang.* hierarchy is for programming languages, however; you'll
find that SGML and XML groups aren't in comp.lang.*. They're in
comp.text.*, because until very recently that was what SGML and XML were
used for. Now, XML is becoming popular as an application data interchange
language specification system, which is a different sort of thing than
comp.text.* covers, but the taxonomy hasn't really caught up.
I think comp.lang.vrml is probably misplaced, but I'm not sure where it
should be put either.
What we really need in an ideal world is something like comp.markup.* for
markup and formatting languages. But that would mostly be wasted effort
since the two heavy-weights of the field, SGML and XML, already have
newsgroups and moving newsgroups is a losing proposition.
> I dunno about the language part, since languages are arguably for
> humans; when it's only for machines, people tend to call it a format or
> a code, don't they?
I'd tend to call it a formatting language rather than a programming
language, but I'm not sure that I buy the idea that SOAP is analogous to a
formatting language.
> Are there any newsgroups for message-oriented middleware per se? Google
> shows comp.object.corba and comp.client-server being the most common
> places that's mentioned. Hmm.
Hm indeed. comp.client-server.soap makes some degree of sense, although
it's not clear that SOAP is exclusively client-server either.
David C. DiNucci
>
> Dan Kegel <da...@kegel.com> writes:
> > I dunno about the language part, since languages are arguably for
> > humans; when it's only for machines, people tend to call it a format or
> > a code, don't they?
>
> I'd tend to call it a formatting language rather than a programming
> language, but I'm not sure that I buy the idea that SOAP is analogous to a
> formatting language.
Regardless of what you or I might call them, the L in XML stands for
Language (and it is a reasonable facsimile of one), and the P in SOAP
stands for Protocol (ditto), and this is known to the people who deal
with them. Since a prime goal of the taxonomy is to help people find
the group, there is some justification for putting XML in a ".lang"
group (though probably not for moving it from its current location) and
SOAP in a ".protocol" group--unless other factors override that.
> > Are there any newsgroups for message-oriented middleware per se? Google
> > shows comp.object.corba and comp.client-server being the most common
> > places that's mentioned. Hmm.
>
> Hm indeed. comp.client-server.soap makes some degree of sense, although
> it's not clear that SOAP is exclusively client-server either.
Hmm indeed indeed. But if people don't think it belongs under
.protocol, client-server may be the most fitting place...at least, for
*now*.
-Dave
Panu Viljamaa
> ...
> Regardless of what you or I might call them, the L in XML stands for Language (and it is a reasonable facsimile of one), and the P in SOAP stands for Protocol (ditto), and this is known to the people who deal with them.
SOAP is a language for 'representing a procedure call'. It is procedure-neutral in the sense that 1) it can run on top of several 'protocols', HTTP included and 2) it can *not* run without a host protocol under it. SOAP message can be stored and reused, and read by humans. What in fact distinguishes SOAP from other 'protocols' is that it is meant for humans to read as much as for machines. So if SOAP is a 'protocol', at least it is a "new type of protocol".
I could see the newsgroup called comp.lang.xml.soap, because foremost I see SOAP as an application of XML. But that would leave UDDI, WSDL etc. out of the topic-area. Discussing SOAP without them is pretty meaningless, like discussing Java without 'Interfaces', or Corba IIOP without Corba IDL.
Perhaps because web-services is the future (!?) , the group should simply be called: 'comp.webservices'
-Panu Viljamaa
David C. DiNucci
> I could see the newsgroup called comp.lang.xml.soap, because foremost I
> see SOAP as an application of XML. But that would leave UDDI, WSDL etc.
> out of the topic-area. Discussing SOAP without them is pretty meaningless,
> like discussing Java without 'Interfaces', or Corba IIOP without Corba IDL.
I agree with this logic.
> Perhaps because web-services is the future (!?) , the group should simply
> be called: 'comp.webservices'
Since there is no current applicable vote in progress, I'll be a bit
less obtuse in my (and perhaps others') earlier suggestions--e.g. when I
said that there may be no better place for this SOAP group "*now*". If
comp.distributed was to appear, I think it would make an excellent home
for a group like this (and perhaps an entire "webservices"
subhierarchy), but since it that appears not to be immediately
forthcoming (if it ever occurs), it is difficult for me to recommend
delaying decision on namespace for this SOAP group.
-- Dave
Neil Crellin
unmoderated group comp.protocols.soap
This CFV is to be distributed only by the votetaker. It is not to be
posted to newsgroups, or mailed to mailing lists or individuals, except by
the votetaker. Ballots or CFVs provided by anyone else will be invalid.
Newsgroups line:
comp.protocols.soap General discussion of the W3C's SOAP.
Votes must be received by 23:59:59 UTC, 20 Feb 2002.
This vote is being conducted by a neutral third party. Questions
about the proposed group should be directed to the proponent.
Proponent: Dan Kegel <da...@kegel.com>
Proponent: Randy Charles Morin <ra...@kbcafe.com>
Votetaker: Neil Crellin <ne...@wallaby.cc>
RATIONALE: comp.protocols.soap
The W3C's SOAP (Simple Object Access Protocol, see
<http://www.w3.org/TR/SOAP/> and the related concept xml-rpc)
appears to be an important standard for open distributed
systems. Microsoft, IBM, Sun, Apache, and scores of other
vendors support SOAP. More and more SOAP-related postings
are appearing on Usenet. However, due to the lack of a SOAP
newsgroup, the discussion is scattered over several
newsgroups. None of the newsgroups are devoted to
non-vendor-specific discussions about SOAP.
CHARTER: comp.protocols.soap
Possible discussion issues include:
END CHARTER.
IMPORTANT VOTING PROCEDURE NOTES: READ THIS BEFORE VOTING
The purpose of a Usenet vote is to determine the genuine interest in
reading the proposed newsgroup, and soliciting votes from uninterested
parties defeats this purpose. Do *not* distribute this CFV; instead,
direct people to the official CFV as posted to news.announce.newgroups.
Distributing specific voting instructions or pre-marked copies of
this CFV is considered vote fraud.
This is a public vote: All email addresses, names and votes will be
listed in the final RESULT post. The name used may be either a real
name or an established Usenet handle.
At most one vote is allowed per person or per account. Duplicate
votes will be resolved in favor of the most recent valid vote.
Voters must mail their ballots directly to the votetaker. Anonymous,
forwarded, or proxy votes are not valid, nor are votes mailed from
WWW/HTML/CGI forms (which should not exist). Votes from nonexistent
accounts or with munged, spam-blocked, or undeliverable addresses are
invalid and will NOT be counted.
Please direct any questions to the votetaker at <ne...@wallaby.cc>
HOW TO VOTE:
Extract the ballot from the CFV by deleting everything before and after
the "BEGINNING OF BALLOT" and "END OF BALLOT" lines. Don't worry about
the spacing of the columns or any quote characters (">") that your
reply inserts. Please, DO NOT send the entire CFV back to me!
Fill in the ballot as shown below. Please provide your real name
(or established Usenet handle) and indicate your desired vote in the
appropriate locations inside the ballot.
Examples of how to properly indicate your vote:
[ YES ] example.yes.vote
[ NO ] example.no.vote
[ ABSTAIN ] example.abstention
[ CANCEL ] example.cancellation
DO NOT modify, alter or delete any information in this ballot!
If you do, the voting software will probably reject your ballot.
When finished, MAIL the ballot to: < vot...@uvv.wallaby.cc >
Just "replying" to this message should work, but check the "To:" line.
If you do not receive an acknowledgment of your vote within three
days contact the votetaker about the problem. You are responsible
for reading your ack and making sure your vote is registered correctly.
If these instructions are unclear, please consult the Introduction to
Usenet Voting or the Usenet Voting FAQ at http://www.stanford.edu/~neilc/uvv.
======== BEGINNING OF BALLOT: Delete everything before this line =======
.-----------------------------------------------------------------------
| 1ST CALL FOR VOTES: comp.protocols.soap
| Official Usenet Voting Ballot <CPS-0001> (Do not remove this line!)
|-----------------------------------------------------------------------
| Please provide your real name, or your vote may be rejected. Established
| Usenet handles are also acceptable. Place ONLY your name (ie. do NOT
| include your e-mail address or any other information; ONLY your name)
| after the colon on the following line:
Voter name:
| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):
Your Vote Newsgroup
--------- -----------------------------------------------------------
[ ] comp.protocols.soap
======== END OF BALLOT: Delete everything after this line ==============
DISTRIBUTION:
Pointers directing readers to this CFV will be posted in these groups:
comp.client-server
comp.lang.c++
comp.lang.java.programmer
comp.lang.perl.announce
comp.lang.python
comp.lang.ruby
news://news.devx.com/xml.general
news://news.microsoft.com/microsoft.public.xml.soap
news://newsgroups.borland.com/borland.public.delphi.webservices.soap
This CFV was created with uvpq 1.0 (Feb 6 1999).
PQ datestamp: 980322
--
Voting address: vot...@uvv.wallaby.cc
Neil Crellin
unmoderated group comp.protocols.soap
RATIONALE: comp.protocols.soap
CHARTER: comp.protocols.soap
Possible discussion issues include:
END CHARTER.
HOW TO VOTE:
| 2ND CALL FOR VOTES: comp.protocols.soap
| Official Usenet Voting Ballot <CPS-0002> (Do not remove this line!)
|-----------------------------------------------------------------------
| Please provide your real name, or your vote may be rejected. Established
| Usenet handles are also acceptable. Place ONLY your name (ie. do NOT
| include your e-mail address or any other information; ONLY your name)
| after the colon on the following line:
Voter name:
| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):
Your Vote Newsgroup
--------- -----------------------------------------------------------
[ ] comp.protocols.soap
======== END OF BALLOT: Delete everything after this line ==============
DISTRIBUTION:
Pointers directing readers to this CFV will be posted in these groups:
comp.client-server
comp.lang.c++
comp.lang.java.programmer
comp.lang.perl.announce
comp.lang.python
comp.lang.ruby
news://news.devx.com/xml.general
news://news.microsoft.com/microsoft.public.xml.soap
news://newsgroups.borland.com/borland.public.delphi.webservices.soap
comp.protocols.soap Bounce List - Please contact me about your vote
-------------------------------------------------------------------------------
No bounced acknowledgments at this time
Neil Crellin
unmoderated group comp.protocols.soap fails 62:10
There were 62 YES votes and 10 NO votes, for a total of 72 valid
votes. There were 4 abstentions and 2 invalid ballots.
For a group to pass, YES votes must be at least 2/3 of all valid
(YES and NO) votes. There must also be at least 100 more YES votes
than NO votes.
A five day discussion period follows this announcement. Unless
serious allegations of voting irregularities are raised, the group
may not be voted on again for six months.
Newsgroups line:
comp.protocols.soap General discussion of the W3C's SOAP.
The voting period closed at 23:59:59 UTC, 20 Feb 2002.
This vote was conducted by a neutral third party. Questions
RATIONALE: comp.protocols.soap
CHARTER: comp.protocols.soap
Possible discussion issues include:
END CHARTER.
comp.protocols.soap Final Voter list
NOTE: This is not [to be used as] a mailing list. The email addresses
are posted only to help verify the interest poll. Thank you.
Voted YES
------------------------------------------------------------------------------
cmeerw_vote [at] fastrun.at Christof Meerwald
clm [at] yoyo.cc.monash.edu.au Cameron McCormack
toivo [at] eleusis.ucs.uwa.edu.au toivo pedaste
rkemp [at] sympatico.ca Icethepuck
alevy [at] almonde.com Andre Levy-Arditti
woyna [at] argonne.com Mark Woyna
jmalina [at] best.com JoAnn Malina
mmrosa [at] bigpond.com Michal Rosa
porjes [at] bigpond.com Jacqui or (maybe) Pete
marco [at] cucinato.com Marco Cucinato
dave [at] elepar.com David C. DiNucci
julesd [at] erols.com Jules Dubois
biow [at] ezmort.com Christopher Biow
smlucas [at] flashmail.com Steven Lucas
Steve.Tolkin [at] FMR.COM Steven Tolkin
gauravrm [at] hotmail.com gaurav mahabir
huang_yanhong [at] hotmail.com huang yanhong
salini [at] iname.com REUS SALINI
michi.henning [at] iona.com Michi Henning
komal [at] isscorp.com Komal Sundaram
rmorin [at] kbcafe.com Randy Charles Morin
morten [at] kikobu.com Morten Primdahl
KenNorth [at] email.msn.com Ken North
tina [at] starbase.neosoft.com Tina Marie
dc [at] panix.com David W. Crawford
medawar [at] panix.com Bassem Medawar
squid [at] panix.com Yeoh Yiu
jimrtex [at] pipeline.com Jim Riley
mra [at] pobox.com Mark Atwood
earthscibbs [at] rogers.com David Ramalho
bill [at] scconsult.com Bill Cole
bruce [at] sportmarkets.com Bruce Duffus
rami [at] sportmarkets.com Rami Mikhail
Reginald.Blue [at] unisys.com Reginald Blue
shollenbeck [at] verisign.com Scott Hollenbeck
steve.vranyes [at] veritas.com <SPAN
corbanaut [at] yahoo.com Nathan Banks
am [at] a-m-i.de =?iso-8859-1?Q?Alexander_M=FCller_Informatik?=
dieter [at] handshake.de Dieter Maurer
a.larsen [at] identecsolutions.de Anders Larsen
Ekkehard [at] Uthke.de Ekkehard Uthke
bouvin [at] daimi.au.dk Niels Olof Bouvin
fungus [at] OCF.Berkeley.EDU Hank Fung
amcmicha [at] Princeton.EDU Andrew McMichael
jkangash [at] cs.Helsinki.FI Jaakko Kangasharju
Juha.Laiho [at] iki.fi
jpc [at] drum.msfc.nasa.gov J. Porter Clark
peter [at] silmaril.ie Peter Flynn
dfrost [at] maths.tcd.ie Dermot Frost
Humphrey.Clerx [at] eurocontrol.int Humphrey Clerx
vote-comp.protocols.soap [at] newton.digitalspace.net Philip Newton
psmyth [at] gmx.net Peter Smyth
shrao [at] nyx.net Shrisha Rao
verbus [at] sonicisp.net Verbus M. Counts
sbfaulds [at] ihug.co.nz Stuart
simon [at] darkmere.gen.nz Simon Lyall
cbbrowne [at] acm.org Christopher Browne
jeffrey [at] carlyle.org Jeffrey Carlyle
crow [at] OrangeBlood.org David L. Crow
avv [at] quasar.ipa.nw.ru Alexander Voinov
neil.padgen [at] mon.bbc.co.uk Neil Padgen
chriseb [at] ukshells.co.uk Chris Ebenezer
Voted NO
------------------------------------------------------------------------------
stainles [at] bga.com Dwight Brown
lostpuppy3 [at] hotmail.com Ignatius Darylmple
pan [at] syix.com Pan
ddmo_1 [at] yahoo.com Darrel Owens
john0 [at] zworg.com John
naddy [at] mips.inka.de Christian Weisgerber
rick [at] bcm.tmc.edu Richard Miller
dougbob [at] charter.net D. David O'Brian
douglasobr [at] netscape.net douglas obornapthy
mmontcha [at] OregonVOS.net Matthew Montchalin
Abstained
------------------------------------------------------------------------------
aahz [at] pobox.com Aahz
van.ette [at] inter.nl.net Robert-Jan van Ette
baloo [at] ursine.dyndns.org Baloo Ursidae
mawdl [at] csv.warwick.ac.uk Jon Thomson
Invalid votes
------------------------------------------------------------------------------
postmaster [at] localhost.com Wiz
! Ineligible address
zed [at] singularity.resonant.org Zed Pobre
! Invalid address: Host not found
--
Neil Crellin, UVV <ne...@wallaby.cc>
David C. DiNucci
>
> RESULT
> unmoderated group comp.protocols.soap fails 62:10
>
> There were 62 YES votes and 10 NO votes, for a total of 72 valid
> votes. There were 4 abstentions and 2 invalid ballots.
While this is a somewhat unfortunate result, it could be worse. There
is a new group, comp.distributed, which is very suitable to traffic on
this subject, and the former proponents of that group (Raj Buyya and
myself) have both recognized and discussed this. We (at least) would
welcome those interested in this subject to post there--and, if they
like, to distinguish posts on that subject by prefixing their subject
with "[soap]". If another attempt at a soap-specific group is desired
again after the 6-month mandatory delay, the traffic on comp.distributed
should certainly help to make their case.
-Dave
-----------------------------------------------------------------
David C. DiNucci Elepar Tools for portable grid,
da...@elepar.com http://www.elepar.com parallel, distributed, &
503-439-9431 Beaverton, OR 97006 peer-to-peer computing
James Logajan
> Neil Crellin wrote:
>> RESULT
>> unmoderated group comp.protocols.soap fails 62:10
>>
>> There were 62 YES votes and 10 NO votes, for a total of 72 valid
>> votes. There were 4 abstentions and 2 invalid ballots.
>
> While this is a somewhat unfortunate result, it could be worse. There
> is a new group, comp.distributed, which is very suitable to traffic on
> this subject,
Wouldn't comp.text.xml be more suitable?
David C. DiNucci
Of course, that decision is up to those posting, not me. If the post
deals primarily with some XML-related aspect of SOAP syntax, then I can
see why the poster might choose c.t.x. However, assuming the post
concentrates on aspects of SOAP that extend beyond XML issues, such as
SOAP's use as a messaging and/or RPC protocol (which is what SOAP is all
about), I personally think that it would be more on topic in
comp.distributed. The fact that the proponents didn't propose it as a
subgroup of c.t.x also suggests to me that they didn't see that as the
logical home for this topic, but I won't put words into their mouths.
IMO,
-- Dave