Life's much simpler when you serve HTML to the browser and do
everything else on the server that you have full control of.
Ah but some people want to distribute _documents_ (software manuals for
instance) that end users place on their own server. In that case it's a
lot easier to set things up for a client side transform that works on
(at least) some specifiable range of clients, rather than try to
document how to set up a server side transformation setup that works on
some corporate IIS box running some unknown flavour of IIs or apache
with some unknown number of mod_zzz extensions installed. Also if the
document is XHTML+SVG+MathML+XForms (for instance) it's not immediately
clear what "HTML" you can serve to gain the same effect.
If you take the view that documents last for a thousand years, but
server scripting technology is lucky to last a decade, then specifying
the linking to the required presentation rules in a declarative PI
rather than embedding that linking in some javascript in a separate html
file has some definite appeal.
No argument with your other points though, there are of course cons to
using the PI as presently specified (and implemented). Another CON that
I haven't seen mentioned (although I've just skimed the thread after
having been away for a while) is that if you serve the file as XML with
a PI, it displays OK in browsers but search engines may not index it or
may (google) index it but list it as unknown format and prompt the user
to view a (mangled) "view as html" version of the document instead.
Of course if the document is only loaded via some javscript on an html
page, it may not get indexed at all by search engines, so that CON might
apply to other technologies as well.
David
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--