[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: GET vs POST

get vs post
Didier PH Martin wrote:
> Hello Paul,
> Paul said:
> > Either:
> >
> >  1. the placeholder language is totally and completely standardized
> > across all of the services. That means not just that the placeholder
> > syntax is standardized but also the variable names and structures are
> > standardized. e.g. 500 services, 1 syntax, 1 set of variable names
> Didier replies:
> The variables do not necessarily need to be standardized, Just look at how
> XQL can help you create you own structure from the tables. 

Didier, if the variables are not standardized then a client that talks
to 500 services must code a 500 "template documents". Do you agree or

Therefore the cost of integration of clients and servers scales linearly
with the number of services. Either this is an acceptable situation or
it is not. If it is not then you need complete standardization -- you
must standardize the variable names.

If it is an acceptable situation then you could just as easily have the
server RETURN the data values in a simple list to the client. The client
could then apply the template.

Here is option 1:

At design time, server declares that available templating variables are
"$foo1", "$foo2", "$foo3", "$foo4", "$foo5" etc.

Client submits


Server fills in values:


Here is option 2:

At design time, server declares that it has available variables "$foo1",
"$foo2", "$foo3", "$foo4", "$foo5" etc.

Client submits:


The server returns:

 <var name="foo1" value="blah1"/>
 <var name="foo1" value="blah2"/>
 <var name="foo1" value="blah3"/>

The client can then apply the template *itself* based on these result
values. If the templating library is properly written then it should
take one line of code to do that.

> ... Fields have
> certain names in the database, these fields could be converted into elements
> or attribute and be named differently. So, only the query rules need to be
> standardized, not the variables. 

If the variables are not standardized you have an O(N*M) integration
problem would is usually a big issue.

> Didier replies:
> The question of functionality resides in the eyes of the client. 

In the Google case, I demonstrated that the functionality of the HTTP
version is a strict superset of the SOAP version so we can focus on
technical issues. 

> Didier replies:
> Yes it may work but we are back to square one, the provider has to develop
> the particular format or the client has to learn and adapt to the provider
> unique format. A kind of "its my way or the highway". 

That is the case *anyway*. You admit that every client needs to conform
to the distinct variable names created by each different server vendor.
In other words: "my way or the highway." There are only two options: "my
way or the highway" or _complete_ standardization so that "my way" and
"your way" always align. Standardizing merely the templating format
still forces the client to conform to the whims of the server: "oops, we
decided to change a placeholder name today" AND breaks easy addressing
AND moves compuational effort from the client to the server.

 Paul Prscod


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.