Re: Re: 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 disagree? 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 <foo> <bar>$foo1</bar> <baz>$foo2</baz> <spaz>$foo3</baz> </foo> Server fills in values: <foo> <bar>blah1</bar> <baz>blah2</baz> <spaz>blah3</spaz> </foo> Here is option 2: At design time, server declares that it has available variables "$foo1", "$foo2", "$foo3", "$foo4", "$foo5" etc. Client submits: http://machine/fetchvariables?varnames=foo1,foo2,foo3 The server returns: <vars> <var name="foo1" value="blah1"/> <var name="foo1" value="blah2"/> <var name="foo1" value="blah3"/> </vars> 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format