[
Lists Home |
Date Index |
Thread Index
]
Hello Paul,
Paul said:
> You haven't described why this is a better way. To me, sending the
> template document to the server is a waste of effort and bandwidth. You
> could ask the server for the *values* and it could send you XML that you
> would combine with your template on the client side using XSLT. Using
> this strategy you do not even have to build a template document and you
> don't have to send it to the server. All of your templating logic lives
> in the XSLT and all of your server-side data is URL-addressable.
>
Didier replies:
OK I accept the challenge ;-) give me some more time and I'll write a more
elaborate thesis/document. Here are my first initial though elements and use
case. I'll work more on criteria to judge an architecture (like for instance
its scalability, its capacity to absorb innovation, its robustness, its
security, etc...) and use these criteria to position the solutions proposed.
a) assumptions:
- The service's "time cost" to prepare the template is irrelevant. The
customer wants a service and knows that it will takes time. The other party
serves the customer and probably charge for it or consider it as an added
value to the customers.
- if the same template is used over and over, the customer can post it on
the server and this latter can re-use the template for the next
transactions. However, due to the implied cost, the server my impose a limit
on the number or the size of the templates stored.
- The server allows ad-hoc transactions and is as much as possible
stateless, since it is more economical and less costly to develop (i.e. no
state management).
- The server is not aware of the document's format the customer requires,
only how to fill the placeholders.
- the document returned may be a rendering document but may also be a *data*
only document. For instance, an invoice or an account statement (i.e.
hierarchical constructs) composed from several tables. The overall format of
the invoice or the account statement is provided by the client.
b) constraints:
- If the query takes too much bandwidth, then it can be compressed on the
client side and made HTTP 1.1. compliant.
- idem for the reply
- The client is not necessary external to the corporation boundaries.
- The server' transactions could be restricted to internal usages and
external agent not allowed to access it.
c) use case:
An ad hoc client (i.e a client) given access right to its account perform a
transaction (i.e. send a query template), for instance an account statement
query template. The account statement is the same as used internally but
different than the one used by the vendor. Instead of imposing to the vendor
to know the idiosyncratic (from the point of view of the vendor) format, the
client provides its own. The returned document is not packaged as a
rendering format but is structured according to the XML specifications and
represents an account statement (i.e. a virtual hierarchical database
fragment). The client stores the document locally and transform it into HTML
(or SVG for superior rendering) with an XSLT template.
d)Results:
- reduced cost from the part of the vendor
- potential cooperative process between business partners
- the rendition is quite versatile since we use XSLT. This allows to display
the result for human consumption in several formats.
- the client has a document (i.e. an account statement) that could be
locally processed or stored for future usage.
temporary conclusion (until I write a more elaborate document):
- With the a posteriori web (i.e. the actual web used by million of people)
we can realize this scenario. Let's call that as in statistics the null
hypothesis or H0
- With the a priori web (i.e. the theoretical web proposed) we cannot
realize this scenario. Let's call that the alternative hypothesis or N1.
Off course Paul as you noticed I took an utilitarian approach judging the
positions on the basis of their utility, cost, versatility and with the
capacity to absorb innovations. My last criteria is quite important if we do
not want to repeat the errors of the past and fall into the dark ages
arguing about the sex of angels :-) Actually based on H1, the use case is
not part of the web. According to H0 it is and is probably already in place
in several corporations - and no, I am not the author all these
implementations :-)
cheers
Didier PH Martin
|
