[
Lists Home |
Date Index |
Thread Index
]
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. But yes, in
the actual status quo, the client may perform the transformation on the
client side and would potentially have to learn a new language with each new
trading partner.
Paul said:
>> The client needs to know the query placeholder names and semantics. This
> is the same as merely getting back a document with the placeholder names
> as keys and associated values and doing the templating on the client
> side.
Didier replies:
The difference is that you do not have to learn a plethora of languages
(form the provider point of view) only a single language, the one of the
placeholder query.
Didier said:
> > Ex:
> > case 1: GET method
> > Actual format is RDF and the client perform a GET with param to get the
> > document. Fine for RDF.
> > A new format has to be supported for instance topic maps, the the
provider
> > has to update the app or create a new one (if we are still using the GET
> > method)
Paul replied
> That's simply not true. The client can do the RDF to topic map
> translation on the client side as easily as they could on the server
> side.
Didier replies:
yes the client can do that. And potentially the client has to learn a
language per trading partner. Not a big productivity gain.
Didier said:
> > case 2: POST method
> > Actual format is RDF, the client perform a POST with a document
including
> > placeholders (and rules specifying how to encode the returned elements).
The
> > provider is not aware of RDF, just the placeholder rules.
Paul replied:
> The placeholder rules must be negotiated between the builder of the
> client and server. This is no easier nor harder than negotiating the RDF
> vocabulary. Actually it is harder, because the client may need
> Turing-complete "placeholder rules" and that is a security threat.
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.
>
Didier said:
> > If we just look at the actual situation with Google, if they want to
satisfy
> > allo groups they need to support a REST like interface and a SOAP like
> > interface, then also RDF, topic maps and tutti quanti. They don't
because it
> > means more cost for them. By extending the concept of template based
queries
> > we resolve this problem (until we find limitation to this solution and
then
> > again we have to seach for a new better one).
Paul replied:
> That's not true. They can support just RDF and then ask people who want
> topic maps to do the conversion on the client side, or vice versa.
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?
:-) 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>
cheers
Didier PH Martin
|
