Re: CSS for transformation

"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