[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin wrote:
> 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.
Well, Cocoon2 is the re-architecturing of Cocoon1 precisely because of
the bad-practice of including a stylesheet reference in a 'source' XML
document, since it precludes easy republication of that file across
different media, using different stylesheets.
That being said, I guess I'm not necessarily agreeing with your
definition of 'the actual offering'. If you have an XML source document
starting like this:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="foobar.xsl"?>
and some foobar.xsl stylesheet stored on the server, the following
sitemap fragment will do what you want IMO:
<map:match pattern="**.xml">
<map:generate src="{1}.xml"/>
<map:select type="browser">
<map:when test="ie6">
<map:serialize type="xml"/>
</map:when>
<map:otherwise>
<map:transform src="foobar.xsl"/>
<map:serialize type="html"/>
</map:otherwise>
</map:select>
</map:match>
<map:match pattern="**.xsl">
<map:read mime-type="text/xsl" src="{1}.xsl"/>
</map:match>
Hm. You'll be flaming me for the foobar.xsl in the sitemap
configuration, not? We are just discussing 'pipeline-aware'
actions/selectors/matchers in the Cocoon-community, which would enable
you to eradicate this annoyance, too: the transformer would be
configured using information found inside the SAX-stream being passed
across the processing pipeline, i.e. the stylesheet reference. It is a
very touchy area however, since lots of people find this breaks the
Separation of Concerns pattern on which Cocoon2 has been build.
> 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.
You are saying retrieving (static) XML docs across the network is faster
than fetching them from local disk? I don't get that one. If you
consider actual XML server offerings being unsophisticated, I doubt it
whether you have Cocoon a real close look - a lot of people are argueing
it is too complex for mundane beings ;-)
<snip/>
> 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 :-)
In the start of my career, I have been working 'purely' with SGML/XML
for 6 years - being a true dochead and all of it. Standards were
everything to me. Implementations were evaluated more in terms of their
compliancy rather than in terms of the offered functionality. After
that, I moved to the 'Internet industry', where people wanted actual
applications to be built which made practical use of XML and the like. I
never learned so much about XML in those past 4 years :-)
Regards,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
|
