Subject: Stepping back, for a moment... From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Mon, 23 Nov 1998 15:17:45 -0600 (CST) |
I've been lurking over the discussions regarding transformation and formatting capabilities for XSL for some time now. I've found this to be of particular interest, as I have long wondered exactly what the point of XSL was at all, given DSSSLs excellent architecture and extensive abilities (if we were ever to get a more complete implementation of it, including the transformation language - not to say that Jade is useless, because it certainly isn't). The only explanation I could come up with was the desire for something more declarative and accessible to non-programmers. In any case, after reading many messages, I have collected and refined my thoughts to the point where I'm ready to take a shot at expressing them. Here goes. First of all, I would like suggest we begin to think in terms of a layered approach. This, in my experience, is the best possible way to meet a broad range of needs in as flexible of a fashion as possible. As an example, think of a basic programming situation. You have a range of tools to pick from in any programming project. You can do your project in machine code. It takes much knowledge and talent, and will take (probably considerably) more time than any other option, but you have *total* control of the machine, and can pull off anything that the hardware allows (and possibly more, if you're really talented :). The next step up would be a fine-grained high-level language, such as C. Here, you have a whole range of tools and abstractions that keep you from having to deal with the myriad of details that machine code would force you to consider. You don't need quite as much knowledge (or, at least, somewhat easier to master knowledge), and could probably complete the project in considerably less time. However, you sacrifice a certain amount of control. The next step up would be a higher level language, such as Java or Basic, where you're a little more removed from the details of the underlying hardware. The same considerations apply. After that, you'd move on to a 4GL, where you largely use visual tools to assemble predesigned objects. Lastly, you'd just use an off-the-shelf application. Here, you're very limited in your options, but you can accomplish the task in (relatively) very little time and with considerably less knowledge and experience required. So, to bring this lengthy analogy to a point, I think our best direction may be to provide standards for the low-level building blocks of these systems, and move up from there. For instance, any type of manipulation, be it formatting or transformation, requires a parsed, structural representation of the document, both input and output. DSSSL uses the concept of a "grove" (which, I might add, is an excellent concept, and should not be lost). Also, the DOM standard could well play into this level. Once an interface to this level (notice I say an interface to, not an implementation of) has been standardized, we can build the next level (or, even a couple of different options for the next level, so us DSSSL sadists could have an implementation of DSSSL on top of this standard, and the rest of the world could have something more sane, right?:). The next level, I assert, would be a transformation language. What about a formatting language? I assert that a formatting language does not belong at the same semantic level as a transformation language. Rather, I assert that a formatting language belongs on top of a transformation language. This basic concept has been put forth here before. Formatting is simply a transformation to a model which describes the physical layout of a document. While I do find the concept of TeXML interesting, I don't think this is necessarily the best way to go, as it sacrifices the multiple output format option, as David asserted here. More on this in a moment. Thus, I believe that the formatting language would be defined in terms of the transformation language. Again, there would be the flexibility for multiple options at this level, each based on a transformation language in the level below. It would even be possible for the same formatting language to be implemented on two different transformation languages. The formatting language would provide a layer of abstraction for the transformations that are really occurring. At the next level (or the same, depending upon how you look at it), would be the abstract representation of the formatted document, otherwise known as formatting objects. Again (and this has been suggested before, as well), there would be multiple options available. Certainly, some standard sets of objects would be needed so that we aren't all speaking different languages, but special tasks have special needs. The DSSSL standard defines a pretty good base set of objects, and would serve as a good basis for a generic set. This is where I see a solution to the formatter-to-transformer feedback problem. By creating abstractions for common situations where feedback would otherwise be needed, we could eliminate the need for a potentially complicated and difficult to implement feedback mechanism. For instance, we could create a formatting object which represents a footnote which may be inlined or placed at the bottom of the page depending on certain criteria, much of which could be controlled by the creator of the formatting object via properties of the object. In practice, this object would encapsulate the TeX code that David spoke of writing. This object could become part of an extended set of objects for more advanced typesetting needs, beyond what, for instance, the average web designer today would need. Indeed, the ability to define new formatting objects which arbitrary semantics will be extremely important as new forms of media become commonplace. Can you imagine where we'd be if a standard set of objects had been set in stone before hypermedia (aka, the web) had come into common use? So, to wrap up this somewhat incoherent rambling, I think some larger scale analysis of what we're really out to do may be in order (and indeed, has begun in these past days), and that the answer may require a fundamental shift in approach. One grand solution may be nice, but is not often feasible. A modular approach opens up the field for a range of solutions tailored to different needs, but does provide some unity of framework. I do have a real world example I'd like to present which demonstrates some of the ideas and motivations behind my thoughts here. It's fairly simple, but demonstrates some important things. I shall try to assemble a presentation of it as soon as I can. Hopefully, it will help to make my ideas a bit more concrete. As always, I am open to any and all comments, ideas, and (constructive) criticisms of my thoughts. -Brandon :) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: The original purpose of XSL..., Guy_Murphy | Thread | Re: Stepping back, for a moment..., David Carlisle |
RE: why split? [was RE: XSL intent , Lawton, Scott | Date | Re: ANN: TeXML enables transform fo, Sebastian Rahtz |
Month |