ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
Re: [xml-dev] SOAP and the Web
by Francis Norton other posts by this author
May 2 2002 5:53PM messages near this date
Re: [xml-dev] SOAP and the Web | Re: [xml-dev] SOAP and the Web
Paul Prescod wrote:

<snip/> 

> You've never done a query and you've never had to
> send complex XML.
> 
This is an argument for not doing Web Services at all. I have to say my 
real interest is in doing Web Services in as REST-y a way as possible.

> When you do it this way:
> 
>  1. the client's access to the data is not mediated by any API or
> messaging interface. This is very much in the XML spirit of "give me the
> data and I (the client) will figure out what to do with it.
> 
OK, this makes sense.

>   2. you cannot generate a "bad query" by trying to get from London,
> Ontario to North Berwick, Scotland (nor North Berwick Maine to London,
> England!). If there is no link for that route then you can't get there.
> 
Um, perhaps I should have chosen a more complex example, eg the Google 
interface, or adding (as the real system does) departure or arrival 
dates and times to the query parameters. I am interested in the boundary 
conditions for where you should use static and dynamically generated web 
pages, but my real interest is in what happens once you've decided to 
implement a dynamic back-end. 

>   3. the client can discover routes, rather than merely generate them and
> test whether they exist or not. For instance it could say: "hmmm. I
> notice a route from London to Glasgow and Glasgow to North Berwick.
> Maybe this is also interesting to my user."
> 
This scales better for transaction volume, but dynamically-generated 
content sales better for complexity - eg how much is the ticket going to 
cost, all the complex stuff I mentioved above.

>   4. the standardization of the "routes" format and the "times" format
> can actually be fairly disconnected. For instance we might use the same
> "times" format for airlines and trains but the "routes" format might be
> different. Or else we could use XML extensibility features to share both
> but have different details on both.
> 
I'm interested in Web Services, allowing program to talk unto program 
over the net while adding as much Web-type value as possible. So 
diversity of formats is not an incentive for me, except in so far as it 
enables better formats to emerge as de-facto standards.

>   5. the server can easily serve these as either dynamic OR static
> documents. The performance advantages to the latter should be obvious. 
> 
Yes, this is a good argument for having a GET interface to Web Services, 
but I'm still not certain whether it is possible to model query 
parameters, for those cases where we admit they are needed, as 
representations of resources.

Thanks - hope your teeth aren't getting ground down to their stumps yet!

Francis.


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl> 
Thread:
Bullard, Claude L (Len)
Didier PH Martin
Francis Norton
Thomas B. Passin
Thomas B. Passin
Didier PH Martin
Julian Reschke
Didier PH Martin
Jeff Greif
John Cowan
Francis Norton
Paul Prescod
Paul Prescod
Francis Norton
Paul Prescod
Andrew Dubinsky
Didier PH Martin

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved