Re: CSS Flow Objects in XSL [WAS: RE: HTML Flow objects that
Mark_Overton@xxxxxxxxx wrote: > > I agree with most of what you say here. I think there needs to be an > abstract set of flow objects that is well defined for XSL. However, I also > think that many output formats will need flow objects which are not defined > in a generic XSL specification. There needs to be some way to take > advantage of the format specific capabilities. That's true. Both DSSSL and CSS provide mechanisms for creating new flow objects. DSSSL requires them to be explicitly declared, in fact. XSL will certainly have such a mechanism also. > I have been building an RTF implementation of the XSL processor. There are > some RTF specific things which I want to be able to include. For example, > RTF has a Table of Contents element. I could try to build this up in XSL > but I would be sacrificing the functionality of the native element. It is not uncommon in our industry to make sacrifices in order to conform to a standard. You haven't persuaded me yet that the sacrifice required to use standard XSL flow objects for a TOC are very large. If you go a proprietary route, you sacrifice compatiblity with every other XSL implementation in the world, which does strike me as a big loss. > The native RTF Table of Contents can be updated if the document changes. So can the XSL table of contents. You just re-run the spec. > I can also change the style of the TOC after the document has been > generated. Changes to the document are usually done in the XML source. Changes to the style are usually done in the XSL source. I admit that it is sometimes convenient to have the formatting application do some sorts of style overrides, but I don't think that the convenience is worth setting yourself apart from the mainstream of XSL usage. > RTF editors can expose other functionality like allowing the user to > navigate by clicking on a line in the TOC. That's just hyperlinking. XSL will (and to a certain extent does) support hyperlinking. > If I build a TOC line-by-line by using XSL core flow objects I would not be > able to gain access to the native formats full cababilities. An Aural > output format is a good example . I'm sure that there would be many flow > objects needed for this format that are not in the core set. An Aural output format is a different case. In that case, the benefits of going your own way massively outweigh the costs of being proprietary. > I think we need to somehow logically seperate the XSL processing of the > rules from the flow object to output format translation. They are logically separate in DSSSL. Insofar as XSL is a simplified version of DSSSL, they will almost certainly be quite separate in XSL also. Even in the current XSL spec., they are quite separate. Flow objects are described in one, self-contained section, and the XSL processing model is described separately. This organization is similar to DSSSL's. Paul Prescod - http://itrc.uwaterloo.ca/~papresco "Perpetually obsolescing and thus losing all data and programs every 10 years (the current pattern) is no way to run an information economy or a civilization." - Stewart Brand, founder of the Whole Earth Catalog http://www.wired.com/news/news/culture/story/10124.html 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