Francis Norton wrote:
>  
>  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.

In what sense is it NOT a web service? The routes probably live in a
database and are dynamically generated. The data is on the Web. You're
talking between a software component on the client side (as opposed to a
browser) and one on the server side. Yes, it "looks like" just a web
page but that's the point: Web services do not have to be architected
using a totally different methodology than web pages.

> ...
>  Um, perhaps I should have chosen a more complex example, eg the Google
>  interface, 

Well I've already shown how you can use a query for the Google interface
in my xml.com article!

>  ... or adding (as the real system does) departure or arrival
>  dates and times to the query parameters. 

You could do all of that through hypertext too. But if you really want a
query interface I don't see the problem.

http://www.flyawa.com/cgi/air?stamp=NEWCOOKY*itn%2Ford%3DNEWREC%2Citn%2Fair%2Famericawest&ai
rline=america+west&rt_ow=Round+trip&depart=PVR&dest.0=PHX&mon_abbr.0=May&date.0=2&hour_ampm.
0=8+am&mon_abbr.1=May&date.1=2&hour_ampm.1=8+am&air_class=coach+%28lowest+avail.%29&adults=1
&children=0&persons=1&ecert_num=&submit1.x=88&submit1.y=3

>  ... 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.

Who said I was using a static back-end? Maybe the information lives in a
database and is updated once per second.

>  >  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.

I'll point out again that just because you can use hypertext and URIs
without using static content!

>  >  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.

Diversity of formats is a fact of life. It is unavoidable in any
architecture. The question is whether the architecture handles it
gracefully or not.

>  >  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.

Query parameters are NOT representations of resource. Query parameters
are part of the address for resources. The representation is the thing
that you get when you do a GET or the thing that you PUT or POST.

 Paul Prescod

-----------------------------------------------------------------
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>