This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: xml-stylesheet p.i. and other options


> I've worked on applications that dealt with 6 kinds of XML
> in, 2 kinds of XML (for different automated recipients) and 6 kinds of
HTML
> (for humans with web browsers) out. There were like 8 different
stylesheets,
> thus requiring some external logic to select which importing stylesheet to
> invoke, based on who needed it and what the input was. Can't do that with 
> xml-stylesheet, 

But you can.  XSL is capable of generic programming.  

It seems you want to have the intelligence reside in the data, and as Andrew
pointed out media types on the pi allow some smarts in that regard.
However, shoving the intelligence down a layer is reasonable (and more or
less what you're going to get with RDDL ?).  Instead of thinking about a pi
as linking to "onewaytorender.xsl" think of it instead as linking to
"makesomechoice.xsl".  

The one thing you are missing in standard xsl is some good way of passing
client knowledge (other than media types) along with the data to the xsl.
With IE JavaScript based extensions can get you around that (although you
may have to assume cookies are enabled), don't know about Mozilla...?  Such
mechanisms do need to be standardized,  but some of any such standards would
have to remain external to core xsl since they would necessarily have to be
specific to running on a client (as opposed to a server).  


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]