Re: Style vs. transformation

["Frank Boumphrey" <bckman@xxxxxxxxxxxxx>]

>>Thus, the discussion aims to find the right match between
power and practical implementability - small footprint, platform
independence, etc<<

Agreed. One of the criteria for the XML specification, which I suppose must
apply to the XSL specification is

"1.1.4 It shall be easy to write programs which process XML documents."

As all application programmers soon as one starts writing software for
transformations and other "innocent" little add-ons the complexity of the
code increases exponentialy. I think that the XSL spec recognises this when
it stipulates

    "2.XSL should be expressed in XML syntax.

    3.XSL should provide a declarative language to do all common formatting
tasks.

    4.XSL should provide an ?escape? into a scripting language to
accommodate more sophisticated formatting tasks and to allow for
extensibility and completeness."

    To have access to a complete scripting language API rather than having
to "roll your own" is a tremendous advantage. As an application programmer I
would hate to see XSL achieve anything approaching the complexity of DSSSl.

>>, those of
>us writing for intranets have a lot of other options and outputs in
>mind. <<

    But those of you writing for intra nets have those options available
already, you dont have to worry about the above issues, you can dictate what
interpretive software your users use, and use Jade if you want to.

    At the moment those of us NOT writing for intra nets have enough
headaches even with such a simple thing as the different interpretations put
on CSS1 by the big two!!

    Frank Boumphrey

-----Original Message-----
From: Tony Stewart <tony.stewart@xxxxxxxxxx>
To: xsl-list@xxxxxxxxxxxxxxxx <xsl-list@xxxxxxxxxxxxxxxx>
Date: Thursday, March 05, 1998 6:46 AM
Subject: RE: Style vs. transformation


>I think of XSL as that set of styling capabilities that we can
>reasonably expect industry-standard browsers to support natively in a
>year or two. Thus, the discussion aims to find the right match between
>power and practical implementability - small footprint, platform
>independence, etc. So it's not just a question of what the author can
>write; it's also a question of what the browser vendors can reasonably
>be expected to implement.
>
>While most people writing XSL will probably target HTML output, those of
>us writing for intranets have a lot of other options and outputs in
>mind. And over time, some subset of those other options will become
>generally available over the Internet too.
>
>Tony Stewart
>RivCom
>"Publishing Structured Information"
>www.rivcom.com
>
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


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