This sounds like a very practical suggestion to me.

If I'm not mistaken, CSS2 still has a way to go toward complete acceptance and 
implementation. Perhaps it can carry the load, grow as necessary in the context 
of emergent XSL and provide more experiential input to XSL design and 
specification.

It might also provide more clarity among non-inner-circle consumers (such as 
myself) as to the practical and meaningful role differentiation between CSS and 
XSL (and DSSSL?). As a witness rather than contributor to the exciting 
innovations that are documented daily on this list, I definitely detect and get 
pulled into the sense of urgency which on one level is very real for someone 
like me -- strategizing, planning, preparing organizations for adoption -- but 
which on another level -- product evaluation, business case writing, adoption, 
implementation, etc. -- looks like a fair ways out with respect to your average 
mainstream organization.

Somewhat related, I guess the only concern I would have about leaving the 
formatting part until later is that the pioneering vendors of things like 
authoring software are either left high-and-dry or to their own devices when it 
comes to how their documents look. How many vendor specific 'style' approaches 
are there now? In my very limited experience I can think of the WordPerfect 
SGML formatting system and the Panorama style system, not to mention what the 
Fuji folks are doing with Hybrick and DSSSL (good on 'em is my two-cents.)

Back to your suggestion: Does this mean that the join (and joint work) between 
CSS and XSL, i.e., formatting properties  (is that what the FP stands for?) 
would ultimately stand a better chance of getting good solid 
design/specification work? Stand more of a chance of being something that 
*really* consistent between CSS and XSL? I started by using the word 
"'interoperates' between CSS and XSL", but I'm not clear that this is the 
intended or desired goal.

...edN

On Sunday, September 20, 1998 3:41 PM, Paul Prescod 
[SMTP:papresco@xxxxxxxxxxxxxxxx] wrote:
> I wonder if the XSL transformation language should be split off and
> designed separately from the formatting objects language. It could be
> called XTrans or something.
>
> A minor concern is that it be general enough. The more major concern is
> with timing: the transformation language could probably be ready for PR by
> Christmas, if James, Henry and other smart people put their minds to it.
> The formatting stuff is much more intricate, requires much more "horse
> trading", is much harder to implement and test out, etc.
>
> In my opinion, the transformation language is going to be MUCH more
> important than the formatting stuff anyhow. Evidence:
>
>  * A Microsoft rep. announed major support for, and excitement about,
> XTrans at XML World. On formatting language: "I don't know, can't make any
> promises right now."
>
>  * W3C employees describe how to use XTrans with CSS-formatting objects in
> a new W3C NOTE.
>
>  * Consider the proportion of questions and interest in xsl-list.
>
>  * Transformations are the backbone of e-commerce and all other forms of
> document interchange. The web doesn't even support the limited
> transformations provided by architectural forms.
>
> We need x-trans for e-commerce and we need it yesterday.
>
>  Paul Prescod  - http://itrc.uwaterloo.ca/~papresco
>
> It's such a
> Bore
> Being always
> Poor
> LANGSTON HUGHES
> http://www.northshore.net/homepages/hope/engHughes.html
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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