RE: XSL Trans
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format