Subject: Re: CSS for transformation From: Tyler Baker <tyler@xxxxxxxxxxx> Date: Mon, 05 Oct 1998 17:59:25 -0400 |
"Philippe Le Hégaret" wrote: > Tyler Baker wrote: > > Well there is speculation and there is fact. The current XSL draft is working > > quite well (at least for HTML output) for the needs of a highly-dynamic website I > Do you call "quite well" the current solution ? This is a post processor solution ! > How can I generate HTML4 strict or HTML4 transitional with this solution ? Should > we add a namespace for all HTML DTD ? I think the idea here is that future web presentation content will be expressed in some XML derivative. HTML falls into that category as I understand that HTML 5.0 will be a child specification of XML. The whole idea of making XSL something which generates output that has nothing to do with XML (such as PDF) I think misses the point of what XSL is supposed to do in the first place. > > am indirectly involved with. I don't think XSL is supposed to be the end-all > > solution for everything, but something simple enough that you don't need a > > complicated programming background just to create a highly-dynamic website. > > > > XSL as not a programming language. It is not a scripting language either. I feel > > XSL's power will be in its simplicity and its ability to change the entire look and > > feel of a website without changing the content or rewriting about 1000 lines of > > JavaScript each time. Writing code to present content is just not a very efficient > > way of delivering dynamic content from a cost perspective. No company in there > > right mind wants to hire 10 JavaScript experts just to get a website going. > > > > XSL I believe will succeed because it will eliminate the need for a lot of the > > scripting solutions as well as the really high-end web-site server products people > > use today to get the job done. In the end, this saves businesses money and that is > > why it will succeed. > I understand your opinion and have no answer for you. But you can't do > a lot of thing with XSL ... Very true. XSL just like XML is not supposed to solve every problem of interchange. Any effort to come up with the end-all solution to a computing problem naturally turns into pure bloat and in the end defeats the original purpose of the effort since bloat and complexity are problems in and of themselves. > For example, if I want to have two result tree from one XML document, I can't. I must > write a program to do this for the moment. You reject the scripting solution because How is this true. In the implementation of an XSL Processor I have been working on it takes a DOM Document as the source tree (as I understand it the Koala XSL Processor does this the same) and builds the stylesheet tree in a proprietary format. You can cache the stylesheet tree or the source tree and process one source tree with multiple stylesheet trees or you can process one stylesheet tree with multiple source trees. Once you have some data structure representing a stylesheet and some data structure representing the source tree, you can reuse them as much as you want. Creating output from a stylesheet tree and a source tree is kind of like French cooking (-: > you don't need a powerful tool. What users, like me, can do with this poor > language ? Should we definitively forget XSL and write programs without specification > or guideline ? > > Philippe. If your project for spitting out processed output is so complex that there is no way XSL can be used and you absolutely need scripting, I would wager you should evaluate your project to see if it is too complex in the first place and see if you can come up with a more elegant solution. Sorry I am impartial here as I mostly regard scripting solutions to be temporary hacked up methods at getting the job done in a brute force manner. I guess when it comes to scripting languages in general you either love them or you hate them (-: Hey I am new to XSL (like everyone else) and do not make these statements as any sort of expert, but I have had more success to date than what I initially thought from my first impressions of the latest XSL draft. My initial perception was that XSL was too complex as it is, so it is interesting to see that some people don't think it is complex enough. Tyler XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: CSS for transformation, Philippe Le Hégaret | Thread | Re: CSS for transformation, Paul Prescod |
Re: CSS for transformation, Philippe Le Hégaret | Date | Getting the © from XML to HTML, Roland Hubscher |
Month |