[
Lists Home |
Date Index |
Thread Index
]
Hi Steven,
Steven said:
Fair enough, but I don't think there is anything inside Cocoon which
forbids to add the stylesheet PI inside the document. Using the
selector, it will send the document as-is (including the PI) to the
browser if it supports XSLT, or does the transformation serverside if
the browser doesn't support XSLT.
Didier replies:
Off course not but this is not part of the actual offering. You'll have
to develop that yourself and maybe to modify the existing code if you
want to inject the stylesheet processing instruction in the XML document
sent to the user agent. Bottom line, it is not there yet, at least in
the case of Cocoon. And based on the very few answers I got on this
topic, it seems that this is not common practice if not a practice not
used at all.
Steven said:
I'm used at thinking the HTTP service is the front-end service of a pool
of transformation servers. You can have a pool of Cocoon servers
front-ended by an HTTP server (Apache using mod_jk, mod_webapp or using
the proxypass_module). You'll end up with session management issues
however if your application needs session failover robustness, if you
don't set up some central session server, too.
I'm kind of intrugued by your inverse vision of a transformation server
being the front-end of an HTTP server - how would that work in practice?
Didier replies:
In practice the transformation engine server is itself an HTTP server
sitting in front of the farm (or is a farm of transformation servers).
The front end servers receives the requests and get the XML documents
from back end HTTP servers. This allows you to perform two load balance.
I made these test in Didier's labs and was amazed to see the improved
performance. I was amazed also to discover the lack of sophistication of
the actual XML server offerings. It seems that the demand is not big
enough to drive innovation in this industry.
Steven said:
Doing XSLT transformation serverside seems to be a best practice in the
current era of inconsistent XSLT support by the major browsers (that is:
while some browser do support XSLT, they don't support it in the same
consistent way - my first try at a stylesheet which was interpreted
correctly by both IE & Mozilla was unlucky.
Didier replies:
This is also the case for HTML anyway. The trick is like we do for HTML:
a) find the common core set
b) use it to encode content/templates
The convergence toward a support of the "recommendations" is not there
yet. We still have to compose with idiosyncrasies. And I guess this will
be the case unless the consumer revolt against the vendors but this
event is as probable as a comet falling on earth. Bottom line, we still
have to adapt to diversity or to develop for a single browser like a lot
of web developers are actually doing (since Microsoft has more than 90%
market share of the browsers). Even in that case, the upgrade to a new
browser version takes at least 2 to 4 years before we reach the critical
mass. Nonetheless, it is still possible to have partitioning of the
transformation process based on the browser version and browser
manufacturer. For corporations, they can even use a proxy server able to
locally transform the document. The proxy server would have to tell the
server providing the XML document that it supports XSLT transformation.
For instance, the Akamai servers support XSLT transformation.
It seems that the XML community is internally focused and more concerned
by URIs than by having a good architecture out there in the real field
to prove that content/rendering separation is the right thing to do.
Instead the community felt into Byzantine discussions. I guess that it
is a sign that we crossed the chasm, that not all the XML technology is
used in reality. It simply history repeating itself :-)
Cheers
Didier PH Martin
|
