W3C home > Mailing lists > Public > www-tag@w3.org > April 2002

RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)

From: David Orchard <dorchard@bea.com>
Date: Thu, 25 Apr 2002 10:55:07 -0700
To: <www-tag@w3.org>
Message-ID: <00a401c1ec93$374bb2a0$540ba8c0@beasys.com>
A lengthy response, but I couldn't get it shorter, despite spending a fair
amount of time.  There are just too many related issues.

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Tuesday, April 23, 2002 5:14 PM
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)
>
>

<snip/>

>
> Fine, so follow it.  In areas where a working group defines
> protocols that
> contradict or violate the architectural basis of the Web and
> the protocols
> that make up the Web, including HTTP and URI, the TAG has the
> right and
> responsibility to challenge that working group to come up
> with a solution
> that doesn't violate those protocols.  That is why we were
> ELECTED by the
> W3C membership.
>

There is some considerable irony that it was an XForms request that brought
up the web services use of GET.  We are having a disagreement about whether
a WG violates the architecture basis or not.  There are many that dispute
that assertion.  If I thought that there was a clear violation of a web
principle, I'd want to use what stick we had as well, though I want less of
a stick than you want.  I sure wouldn't say change or die just because I
felt like it, ESPECIALLY with so much of those paying companies interested.
Agreed we challenge them.  Disagree that we can disbar them.

> > I don't consider myself or my company to be marketing
> consultant or being
> > part of mass hysteria.  The fact that the customers that
> are doing web
> > services and using web services products don't feel a
> strong need to use
> > HTTP (while using URIs, XML and much of HTTP) in a manner
> that you like,
> > shows where any hysteria on this issue lies.
>
> No, it shows where ignorance of the Web architecture can lead
> any group
> of people to design a solution that breaks it instead of becoming part
> of it.  If you told people the truth about what will happen
> to SOAP over
> HTTP as soon as firewalls are upgraded to defend against them, those
> customers wouldn't allow that technology in the door.
>

Enlighten the world then.  You haven't been a shrinking violet so far.  This
to me is one of the most interesting arguments I've heard, but you haven't
justified it.  As I said after the TAG call had formally ended, I'm
extremely interested in pursuing this topic further.  I'd really like to see
how the different firewall designs would look like.

Can we recuse the discussions of hysteria from this?  I'd like to point out
that many of the REST or die camp are certainly being hysterical this past
little while.  It does us no good on this forum to start comparing which
camps are being hysterical.  I'll follow you there if you want, but I think
both of us would rather do other things.

> > I find it interesting that you feel comfortable being part
> of the TAG at
> > the
> > W3C, which was voted on by the W3C Members, but you are
> uncomfortable with
> > Web Services as-is at the W3C, also voted on by W3C
> Members.  And if the
> > Web
> > Services folks don't do what you think is right, they
> should just all go
> > somewhere else regardless of the process that got us where
> we are.  I'd
> > observe that in the TAG elections, 3 of the 5 elected
> members are members
> > of
> > the SOAP WG.  I interpret this as yet another plank in the
> mandate that
> > web
> > services at the W3C is important to the membership.
>
> So what?  First of all, I have never been "comfortable" being part of
> the TAG.  I am living with it because the members of my nonprofit
> organization are sick of seeing the principle of simplicity in Web
> standards being ignored within the W3C, mostly because of that very
> same Process that values membership money over technology merit.
> This is my (perhaps hopeless) attempt to make the W3C responsible
> to the public, rather than just the members.
>
> I am just one of nine votes on the TAG.  I am tired of people
> defending
> bad technology in terms of how many people are willing to
> make money from
> it rather than how many people have successfully deployed it
> within the
> Internet environment.  Nevertheless, I would have no problem
> with the W3C
> being used as the specification cauldron for SOAP as "XML Services".
> I've built Web services (small "s") for a living and Web
> infrastructure
> for the public.  People wanted me on the TAG because I have actual
> experience in implementing Web systems and writing Web standards,
> not because I am respectful of the W3C working process.
>

Right.  I think you have other strong credentials as well, BTW.  You
represent at least one important constituency.  But it ain't the only one.
And the pay to play members have rights under the process, and have followed
the process.  More on the naming issue later.

> > I'm prepared to continue discussion and gain understanding
> of yours and
> > others views - and I've repeatedly demonstrated that - but
> let's not
> > ignore
> > what the member companies have expressed.  They can change
> their mind I
> > guess, but I frankly don't see that going over well on
> ac-forum.  Again,
> > I'd
> > like avoid the process question and focus on the technical
> merits as
> > befits
> > TAG discussions.
>
> The TAG does not exist to rubber-stamp the products of working groups.
> We have identified, very clearly, a deficiency in regard to SOAP: it
> does not allow URI to be used to identify important resources.  That
> technology, as it is currently defined, has no relationship
> to the Web.
> The working group should either fix that deficiency or clearly
> indicate that the technology is not intended for use with the Web.
>
> If you don't agree that this kind of issue is precisely why the TAG
> exists, then please enlighten me as to why the AC doesn't simply
> vote on matters of Web architecture and let popular opinion decide.
> I will be happy to resign if that is the kind of standards you want.
>

I agree the TAG should never rubber-stamp products of WGs that it finds at
fault.  But I disagree with the assertions made about SOAP and it's HTTP
binding, the relevence of the POST/GET claims compared to today's reality,
and many others have.  In my mind there is a direct relationship between web
services and the web.  So we disagree about some things, that doesn't mean I
want you to resign.  I really do understand why you consider this such a
make-or-break issue.  FWIW, The extreme furor that this is causing has
convinced me that the TAG should be extremely careful about what it decides.
This is probably the biggest issue that the TAG will work on.  I'm not sure
yet whether it's good or bad that we hit this one so early on, but that's
life.

You are purposefully ignoring the process that got web services, and other
things, at the W3C.  Probably because you are not part of the process.  But
many are part of the process and your views as a TAG member are not
pre-eminent over theirs.  There are many things the W3C has decided to do.
For example, the W3C decided to do the XML Work.  In retrospect, XML appears
to have little to do with the Web as you see it - it has little directly to
do with URIs or HTTP.  I'm wondering whether you also think that XML
shouldn't have been done at the W3C.

The W3C Members have decided that they want Web Services done at the W3C.
That's what the AC members voted on, and what I was commenting on.  You, and
a few others, have suggested that because the way an optional part (the HTTP
binding) of 1 spec (the SOAP adjuncts) is worded, that the whole web
services activity should just go somewhere else if it doesn't change,
despite that a lot of people disagree with your considered opinion.

I never ever in my wildest dreams thought of the TAG as a committee that
could shut down an entire activity.  I shudder to think of what would happen
to the Semantic Web or XML activities if they violated your views with that
much power.  I have no interest in being part of a group.

The name of "Web Services" is irrelevent.  If Web Services changed it's name
to "XML Internet Services", or something like that, how would your problems
be addressed?  Especially if it were done somewhere else?  The software
would go on doing whatever it did, even if incorrectly.  If "XML Internet
Services" were going to defile the web as you see it, it doesn't matter the
name.  A Web Service by any other name ....  But as a champion of
open-source, I would think that you would want it to be done in as open a
forum with the most reasonable IPR terms you can get.  I won't shroud myself
in the veil of big-business or open-source, but my personal and company
goals are that web services should be done in as open a forum with the most
reasonable IPR terms as we can get.  That you think a simple name change
would make all the problems you see go away has me really puzzled.  It's
what the software does and IPR that counts.

The TAG should do it's job of making architectural recommendations and
documenting web principles.  The TAG should not and does not have oversight
over the chartering of activities and working groups.  There is a difference
between power over architecture and influence over charters.  The TAG does
need to discuss the impacts of it's works - what we're doing here - but not
so far as to drag an Activity out of it's home at the W3C.  I've suggested
how to deal within the process and activities for how to influence the web
services activity.

I suggest that you drop the line of attack that web services must change or
it should go somewhere else, and drop the possibility of web services not
being at the W3C because of some the TAG says.  Again, I'm game to go there
but I'll be holding my nose.  You know full well that I can't let the
process issue drop if you keep at it, especially if other TAG members are
strangely or not-so strangely silent.

Let's get on with the sausage-making and do the work to figure out how to
meet the broader community's needs.

Cheers,
Dave
Received on Thursday, 25 April 2002 15:59:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:06 GMT