[
Lists Home |
Date Index |
Thread Index
]
Hello Paul,
Didier said:
> > - if the same template is used over and over, the customer can post it
on
> > the server and this latter can re-use the template for the next
> > transactions. However, due to the implied cost, the server my impose a
limit
> > on the number or the size of the templates stored.
> > - The server allows ad-hoc transactions and is as much as possible
> > stateless, since it is more economical and less costly to develop (i.e.
no
> > state management).
Paul replied
> The two points above seem to contradict each other. If there is a
> requirement that the server remember query templates for reuse then the
> system is not stateless and can use POST without guilt.
Didier replies:
Not necessarily, for recurrent usages, the query template may be stored on
the server and then invoked with a GET. Otherwise with a single POST. From
this we can deduct that to use the GET method, we have to store something on
the server prior to the transaction. In contrast, the other method (i.e.
POST) does not require that and ad hoc transactions can be completed in a
single stateless operation. Off course, some clients may choose to always
use a two step process or some servers may restrict their usage to a single
step process and then prevent to store any template. These two conditions
(staed above) are not to be taken as mutually exclusive (I did not say they
are). Sorry, I though I was clear enough.
Paul said:
> But more to the point, you haven't convinced me that the CLIENT needs to
> specify the XML structure of the data returned by the SERVICE. More
> often, the service has a view of the data that the client queries or
> filters. The service returns the requested data in an XML format that it
> chooses (e.g. GoogleML for Google, RSS for Meerkat, etc.).
Didier replies:
I didn't said that they *need* to specify the XML structure in the absolute
only that to reduce cost (from the server point of view) and allow
flexibility, the server allows the client to specify a structure and that
this kind of transaction may reduce the transaction frictions between
trading partners. The server's contract is reduced to fill the placeholders,
not to impose a full document structure or its view of the world to the
clients. Now if the placeholders are expressed in a standard way, we gained
something, otherwise I agree, we gained very little in the process (hoops I
forgot to say that the placeholder are to be standardized either as de
facto, consortium recommendation, ISO standards or as per industry
convention).
Also, the templates offer a certain processing economy. If the entire world
has not standardized on a business transaction (i.e like edifact or X12) or
if two business partner operate within two different ecosystems (i.e.
different business document formats), then this could be used to minimize
the transaction cost. Notice that the client obtains a track record of the
transaction or that a middleware can keep track of the transaction as a
complete document (Ex: an account statement).
Now, you would convice me of the merits of the actual "a priori web
proposal" with more complex business applications that the ones mentioned.
Paul you took the socratic position to let me express my opinion, now let me
take that position and ask you how you would resolve the use case I
mentionned in the last message.
Paul said:
> Perhaps you could explain to me, for instance, how the Google web
> service would be improved if you could push an XML "template" to them.
> All you would do is transfer a client-side XSLT transform, from GoogleML
> to ClientML to the server.
Didier replies:
In the case of the google example, they could have picked a solution a la
Moreover [1] and provide all the formats suited to the clients needs[2] or
simply let the client submit their format and then fill the placeholders. If
you want to standardize the transaction (or at least follow a consortium
recommendation not an international standard), then Google could use XSLT
templates and present their information universe as an infoset. The template
being resolved on the server side, the document is now formatted the way you
want (SOAP, RDF, topic map, semantic links, etc...) This way, if a new
format comes out of the mind of creative people it is automatically
supported by the information provider without additional cost or development
delays. The information provider doesn't necessarily have to know the
format's existence. Otherwise, we are trapped with the same problem as we
encountered during the big iron era: development delays. Now question of
bandwidth, if Google can afford to support SOAP I guess that bandwidth is a
"no issue" for them.
PS: Message to Microsoft, Sun and IBM legal departments: if this process has
not been patented by you then too bad, this message represents prior art :-)
Sorry I couldn't resist teasing the gorillas :-)
cheers
Didier PH Martin
[1] http://www.moreover.com
[2] At the rate new XML based languages are created, I doubt that Google
could be up to date and rapidly introduce new formats to the market.
|
