Re: Fwd: Re: [xml-dev] What does SOAP really add?

[Paul Prescod <paul@prescod.net>]

Didier PH Martin wrote:
> 
>...
> 
> 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. 

I personally feel that it would be simpler to design the system so that
it chooses one model or another. Either queries are resources that live
for a period on the server or they are not. Otherwise your clients and
servers need to negotiate which model is acceptable to each when they
first encounter one another.

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

How?

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

I am completely not understanding this process.

Client sends the server:

<myformat>
  <abc><temp:template select="$foo"/></abc>
  <def><temp:template select="$bar"/></abc>
</myformat>

If it has already negotiated with the server that "$foo" and "$bar" will
be available then it would take no extra effort for it to work with a
document of the structure:

<blah>
 <foo>...</foo>
 <bar>...</bar>
</blah>

or even:

<values>
  <key name="foo" value="..."/>
  <key name="bar" value="..."/>
</values>

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

I believe that the level of standardization required is exactly the
same. In order even to *ask* for the values, (in this case $foo and
$bar) you will have by necessity learned the details of the service's
data model. Furthermore, by doing the transformation on the *client* you
can use a complete, Turing complete language like XSLT or DSSSL or
Python. But when you do it on the server, you are necessarily restricted
to a very restricted language which in my opinion will not scale up to
any kind of half-way complicated system (loops within loops etc.).

What you are describing is like if on today's web we sent a CSS file to
the server to tell them how they should render the data. Better we
control the application of the CSS on the *client*.

So I'm going to stick with my answer that templating and other types of
transformations are, in the web architecture, done on the client side.
You can of course use HTTP POST (with or without SOAP) to shift that
responsibility to the server, but I see no benefit.

*Negotiating the templating keywords is exactly as much effort as
negotiating a shared XML vocabulary*

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

In my model, the server would be stateless. The template would live on
the client. The server would use HTTP's content negotiation to present a
menu of various vocabularies to the client. If the data output is simple
enough to support your replacement model, then it is simple enough to
support a key/value pair model as I described above. This can trivially
be used to do the transformations on the client side. All of the
server's information resources can remain addressable.

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

I'm sorry, I completely do not see how moving the transformation from
client to server changes any devlopment delay issues. Let me give a
concrete example. 

Let's say the server has news syndication information. Let's say it
supports XMLNews but not RSS. Your solution is for the client to push a
document like this:

<rss>
  <title>$title</title>
  ...
</rss>

This requires the client and server to have negotiated what "$title"
means. If they have already negotiatied this then they could have just
agreed that the server would return:

<our_shared_ml>
 <title>...</title>
...
</our_shared_ml>

Or maybe they use XPaths. If so, then what are they using XPaths *into*.
Whatever that thing is, it is the real resource and should just be
returned in XML.

Let me be concrete again. According to your theory, function A is more
flexible and adaptable than function B:

def A():
   return arg1, arg2, arg3
print A()

def B(template):
   return template % (arg1, arg2, arg3)
print B("Value 1: %(arg1) 2: %(arg2) 3: %(arg3)

But they are *exactly as flexible as each other* because you need to
know about "arg1", "arg2", and "arg3" *anyhow*. Therefore it is just as
good to return the data as close to "raw" as possible and let the client
do the templating.



 Paul Prescod