[
Lists Home |
Date Index |
Thread Index
]
Michael Day wrote:
>>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."
>>
>>
>
>Yes, that is why I believe that XSLT is best used for general
>transformation tasks, rather than for styling documents.
>
>Pipelining is an important addition to XSLT and will certainly be useful
>for some transformation tasks. However I believe that it will not make
>XSLT any more suitable as a styling language, as it will make the
>connection between the input and output documents even vaguer than it is
>at present. Customising complex styling transforms will still be very
>difficult without detailed study of the default templates.
>
>
That complexity is a trade-off which many apparently feel is well worth it.
Complex styling transforms of the kind enabled by XSLT, aren't plausible
in CSS AFAIK.
One should use the best tool for the job. Sometimes that does mean
avoiding XSLT and conveniently attaching CSS styles. Other times it
means going with a full-bore transformation. The diversity of glitches
in implementations of both XSLT and CSS mean that in the general case
there is rarely a clear-cut path. Both are valuable components in the
toolkit.
>>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.
>>
>>
>
>Or perhaps an unfortunate choice of styling model. By choosing to
>transform the document structure tree into an entirely separate page
>layout tree, (rather than annotating the document with formatting
>properties as in CSS), the styling becomes harder to specify and to
>customise.
>
Well, it was a deliberate choice based on consideration of the needs of
a more diverse audience than that served by CSS. Also, since we have CSS
as a separate Rec, there isn't much point in duplicating it. The
complexity is a trade-off, but one which is well worth it considering
the large number of formatting problems which are mitigated through
transformation.
OTOH, could there be a cascading transform? Would it be more or less
difficult to understand?
Regards,
Mitch
>Best regards,
>
>Michael Day
>
>
>
|
