[
Lists Home |
Date Index |
Thread Index
]
I would say that your conclusion mirrors the rationale for XSLT
"This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents."
But you probably meant "XSL", didn't you?
I recently ran a survey of XSLT users. One of the things that came up a few times was modularity; respondents pointed at pipelining as an alternative to xsl:import.
The idea here is that run-time processing is what mattered to them. Pipelining allows
stepwise transforms, to more effectively impose formatting policy in staged increments.
IMHO, the language isn't so much at fault. It is the presumption of a limited run-time model. Or simply the lack of maturity in what really is a family of complicated formatting processes.
- Mitch
Michael Day wrote:
>>| This will allow you to convert books written in DocBook XML into PDF files
>>| or PostScript output, without using XSLT or XSL-FO.
>>
>>I'm not sure I see why that's a particular benefit, but ok :-)
>
>
> Simon St. Laurent summed it up well on his O'Reilly blog:
>
> While it's certainly possible to tweak [XSLT] stylesheets to render a
> particular document, I have to admit that I really miss the cascade of
> CSS and its much easier element-by-element tweaking capabilities.
>
> There are best practices for creating tweakable (well, modularized)
> XSLT stylesheets, but you're much more at the mercy of the creator of
> the stylesheet with which you're interacting.
>
> -- http://www.oreillynet.com/pub/wlg/3363
>
> The cascading approach of CSS makes it easier to customise the formatting
> of languages like DocBook that have large, complex default style sheets.
>
> For example, if I wish to have an indent on paragraphs in my document, I
> need only add the following rule to my user style sheet:
>
> para { text-indent: 5mm }
>
> However, the XSLT based approach is more complicated. I could create a
> template for para, but then that would override *all* of the default
> styling for paragraphs, which is not what I want. The lack of additive,
> cascading templates in XSLT means that I would need a detailed knowledge
> of the structure of the default style sheets in order to customise them
> effectively, whereas CSS allows me to concentrate on the structure of my
> documents instead.
>
> For this reason I believe that CSS is a more effective approach for
> styling XML documents, while XSLT is best used for more general
> transformation tasks, such as generating documents and reports from
> "data-oriented" XML, or migrating from one vocabulary to another.
>
> Best regards,
>
> Michael Day
>
> (I've copied this message to xml-dev, as it seems to be a more suitable
> list for this kind of discussion than docbook-apps).
>
|
