[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin wrote:
>
>...
>
> Didier replies:
> Yes, the main point is that the client provide the structure, the server has
> only to support the template placeholder queries not the full document
> structure. For instance, let's say that tomorrow, a new XML format is
> popular. Actually, the client will have to wait that the provider update the
> app or write a new one to support the new format (with a GET request).
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.
>.... But
> in the case of the client being able to send the new format that includes
> the query placeholders, the provider has noting new to develop and the
> morning after the new XML spec is out, the client can perfrom its request.
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.
> 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)
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.
> 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.
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.
>...
> 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).
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.
Paul Prescod
|
