[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin wrote:
>
> Hi Paul,
>
> Paul said:
> > That's not true. If the client wants, it can do a transformation on the
> > new one. This is no easier nor harder than sending the transformation to
> > the server. When you send a "template" with "placeholder queries" you
> > are just sending a simplified transformation. You're asking the server
> > to do the client's work for it but there is no real benefit.
>
> Didier replies:
> True, the client can do that. However, the client will have to learn the
> provider's format in order to transform it. It we got a common placeholder
> format, then we would have only one thing to learn , otherwise, we have to
> learn several formats. So the benefit is that we have to learn one language
> (the placeholder query rules) and not several set of languages.
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
or
2. the placeholder language is NOT standardized, in which case every
client has to be specifically coded to talk to every server. e.g. 500
services, 500 sets of variable names.
The first is equivalent to not using placeholders and standardizing an
XML vocabulary that returns the same information. 500 services, one
vocabulary.
The second is equivalent to not using placeholders and forcing the
client to understand every vocabulary for every server. 500 services,
500 vocabulries.
There is some data. There is a template. There is a language that
combines them. Whether it runs on the client or the server is not
relevant to the issue of whether there are N*M client and server
connections or just N. It is totally a question of standardization or
lack thereof.
>...
> Didier replies:
> Off course if the placeholder rules are ad hoc, nothing is gained. If the
> placeholder rules are standardized then you have leverage: one language to
> learn in order to adapt to different formats. There is, I think, one
> potential problem with the approach and you raised the issue. The question
> derived from this issue is: "Do we need a Turing complete language for this
> task?". There is some research to do but potentially, a query language that
> includes loops may fulfill a lot of needs. But I agree, the query
> language's versatility or lack of can be the make or break of the concept.
Could you please show me an example of a template document so we could
talk more concretely?
>....
> Didier replies:
> So this is what Google do with SOAP doesn't it? (provide a single interface
> and ask everybody to either use it or adapt to it by locally transforming to
> their own format). So why they should publish with a REST like architecture?
> :-)
I'm not asking Google to support an infinite number of different
interfaces. I'm asking them to figure out which one is the MOST
functional and let people dumb down to other ones on the client side.
> ... See, each group/community wants the provider to support their pet
> API/architecture. Two options, we create/design an architecture allowing
> variance and economical ways to satisfy that need for variance or we do like
> Google does, satisfy what they think is the biggest market share and tell
> the others to "adapt" (by performing a local transformation to convert into
> their own format). The monkey is on their shoulder now, they can use a style
> sheet to transform the provider's format. <End of demonstration>
Doing the transformation on the server side buys the customer nothing.
If Google's templating language calls a quer result "queryResult" and
AltaVista's calls it "searchResult" and Lycos calls it "result" then I
need three templates for those three services. I might just as easily
have done through XSLT transforms on the client side.
Conversely, if the three have all standardized on "queryResult" then
obviously they are following some published standard somewhere and the
standard might as well have been an XML schema or DTD rather than a
"placeholder variable names" standard.
Paul Prescod
|
