> What is a "skin" to you? Some sites need dramatically different XSLT to produce > their final result.
A "skin" to me is the ability to swap look and feel within a single application. Knowing a bit about what you guys do it seems to me that you've got a different kind of problem (not sure what you'd call it), but I can see how you might consider it similar to skins. > Site 1 needs to use an HTML 4.01 table based layout with pixel precision to sew > together images to produce a flashy kind of site. > > Site 2 wants to use XHTML 1.0 CSS layout and does not require pixel precision. > > The skinning of the site is done in two completely different layouts (and output > types). > > How would you do this without different skins? I think you mean "without different XSLT"? If you really wanted to jump through hoops I could see how one could dynamically create the XSLT from XML based site specifications that you created. However, in this case it might be just as pragmatic to use different XSLT, but I'd be very careful on who I let create the XSLT... <snip> > That being said, we have been very selective as to who we take on as a client (we > are a pretty small company). I have turned away potential clients that I found > suspicious. And we have been doing most the XSL(T)... There you go... :-) >> Other than that, if Saxon (or the underlying Java engine) has any >> potential buffer overflow problems, or other Sandbox leaks then you've >> given people a nice Worm building environment (since XSLT is Turing >> complete)... > > Wouldn't this be a problem with anything? Well only if you give people a way to exploit it: using XSLT as a script engine potentially lets any script writer have a go at cracking open the bugs. If the XSLT engine is only running XSLT that you control then only you get to expose the bugs... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
