Re: why split? [was RE: XSL intent survey]

John E. Simpson <simpson@xxxxxxxxxxx> wrote:

>Something just occurred to me that might let us "have it both ways." I
>offer it in the hopes that it will either be peppered with buckshot as
>essentially unworkable, or not :).

>
>The discussion has been framed as a choice between splitting XSL into
>transformation and presentation components, and putting both of those
>components into a single baseket, as it were. I wonder if there might be a
>"middle way": supersetting XSL with a more robust transformation-only
>level. As I'm envisioning it, XSL-Core would provide all of the formatting
>facilities and a modicum of transformations -- certainly at least those
>necessary to make the formatting work. XSL-Enhanced (or whatever) would use
>the same "syntax" as -Core but provide a richer, more complex set of
>transformational capabilities (such as those possible with full-blown DSSSL
>or TeX, maybe, although I'm not familiar enough with either to say for
sure).


The danger in this is that XSL-Core would slowly include features from
XSL-Enhanced. Each XSL-Core processor would also implement some enhanced
features... we'd end up with a spectrum of languages (each tool with his
own), with a too-complex XSL-Core language ad an attempt to define a commeon
baseline.

All this may be prevented by in theory by the standard body. History shows
that such bodies are not very good at this thankless job. It is very
difficult even under the best of circumstances.

Share & Enjoy,

    Oren Ben-Kiki.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list