W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: Issue 5; GET vs GetLastTradePrice

From: Katia Sycara <katia@cs.cmu.edu>
Date: Fri, 3 Jan 2003 11:22:39 -0500
To: Walden Mathews <waldenm@optonline.net>, "Newcomer, Eric" <Eric.Newcomer@iona.com>
Cc: www-ws-arch@w3.org

 it would help me if you could mention examples of the constraints that
would be needed in the architecture specifications, as well as the pitfalls
these constraints could avoid. Also, some examples of well known pitfalls
would be helpful too.
 Thanks, Katia

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Walden Mathews
Sent: Friday, January 03, 2003 11:00 AM
To: Newcomer, Eric
Cc: www-ws-arch@w3.org
Subject: Re: Issue 5; GET vs GetLastTradePrice


At your invitation below, I've started to review the current editor's draft
of the
architecture document.  I'm just a little way into the "Extended Web
Architecture" section.  My comment at this point is that I don't think the
document I'm reading would have provided the kind of guidance needed to
avoid the pitfalls I mention below.*  I was dismayed to find that the "Basic
Architecture" section accomplishes little more than describing what most of
us would readily recognize as client-server, plus a directory function.  Why
directory function is so prominently featured in the basic architecture, I
understand at all.  Most notably, there seem to be no constraints to speak
in this document.  How do you avoid pitfalls without constraints?

Not to get too far off the track. I'd be happy to give further comments and
suggestions on the applicability of the architecture document to projects
the one I experienced last year.  But there is still this claim you have
about document mode "middle ground", which I would like to better


* On proofreading this before sending, I'm wondering at this point if the
document is intended for that purpose.  One reason it wouldn't have helped
that I don't think I could have convinced anyone on the project to read it.
very wordy, and frankly quite contradictory and confusing in many places.

----- Original Message -----
From: "Newcomer, Eric" <Eric.Newcomer@iona.com>
To: "Walden Mathews" <waldenm@optonline.net>
Cc: <www-ws-arch@w3.org>
Sent: Thursday, January 02, 2003 11:00 AM
Subject: RE: Issue 5; GET vs GetLastTradePrice

> Walden,
> I hope the WS Architecture work will clarify the picture and provide some
"best practices" information that will help avoid pitfalls.  If you get a
chance, please review the current editor's drafts and give us your comments:
> http://www.w3.org/2002/ws/arch/
> Regarding tools, I only intended to refer to standard tools such as XSLT,
DOM, and Sax...sorry if I wasn't clear on that point.
> Eric
> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Thursday, January 02, 2003 10:37 AM
> To: Newcomer, Eric
> Cc: www-ws-arch@w3.org
> Subject: Re: Issue 5; GET vs GetLastTradePrice
> Eric,
> > Yes, I was trying to draw a distinction between the case where
> applications share semantic information totally out of band, and the case
> which applications rely totally on automatic discovery mechansisms to
> semantics.  I think there's a middle ground that we sort of avoid when we
> polarize the discussion as "REST vs RPC/SOAP" or "specific interfaces vs
> generic" or whatever.
> I'd like to get clearer on what that middle ground is.  Last summer I got
> involved in a project that
> had already decided to use XML in a "document" mode as opposed to a "RPC"
> mode, but the
> distinction was only skin deep, at least according to my analysis.  The
> approach was still leading
> these developers in the direction of inventing a ton of new protocol, when
> very little new protocol
> was actually needed.  In effect, they were doing the work that the
> RPC-framework tools do, so
> they were getting the worst of both worlds.  I wonder if the WWW
> architecture will provide the
> guidance they would need for avoiding that pitfall.
> >
> > What I was trying to say is that XML tools can help reduce the custom
> coding effort, not eliminate it altogether.
> >
> Oh, I didn't realize this was about tools.  Would it be feasible to have
> discussion sans the
> mention of tools?  Are tools really central to the problem of getting two
> applications to understand
> each other, or are they an optimization to apply deeper solutions to that
> problem?
> Does the inclusion/exclusion of tools affect your view of what that
> ground" is?
> Walden
Received on Friday, 3 January 2003 11:23:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:01 UTC