[
Lists Home |
Date Index |
Thread Index
]
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
|
