- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Thu, 27 Mar 1997 11:54:37 -0500 (EST)
- To: Peter@ursus.demon.co.uk
- Cc: w3c-sgml-wg@w3.org
> The point here is that I would rely totally on a Java based solution at the > bottom layer. It isn't possible to ask people to install a (platform-dependent) > scheme compiler, Jade engine, etc. This is > because I want my applications to work in a Java environment. Maybe perverse, > but I cannot expect my colleagues to download Jade and learn even simple DSSSL. > Java is more distributable. DSSSL is no harder to get working in a Java environment than XML itself. In either case you must implement a parser and some code to do work the data. Luckily NXP/Lark are XML parsers, Kawa is a DSSSL parser, and you are already writing the Java code to "do the work" once the job of the DSSSL interpreter is done. > Probably. Stylesheets are seen as publishers' tools or beautifiers for > display. They are not seen as things which transform documents in a > discipline-relevant manner. If it will help in your community, you can call them by their technical names: style specifications or transformation specifications. > It works as long as there is a 1-1 mapping. I suspect that there will be > problems with more complex structures. But at this stage I suspect we > don't understand them very well anyway. I'm not sure what you mean here. In the document domain people have been working with more complex document structures and mappings for a long time. > This may be my ignorance (and the WG is not the place to work it out) but > I get the impression that stylesheets are primarily for transforming documents > and formatting them, and not for adding behaviour. For example, a lot of > our methods involve mouseUp(), etc. routines or discipline-dependent > processing. Those would be the behaviours of your flow objects. But you need a way to attach those flow objects to arbitrary nodes in the grove (elements in the document): to transform arbitrary structure into well-defined semantics. That's were DSSSL can come in. I think that this is worth discusing in the WG because most people are probably not familiar with DSSSL yet. > This sounds very interesting. Whether our data transform into flow objects > easily I don't know. Hopefully it will become clearer when there are some > demonstrators working. My understanding is that you can invent whatever flow objects you need for your discipline, or else use the transformation language. Here's what the former would look like (this is me working with a totally hypothetical DTD and flow object set that is vaguely chemistry related): (element water-molecule (make H2O-object)) or: (element water-molecule (make molecule hydrogen: 2 oxygen: 1)) Now here is where the power of DSSSL comes in, over *either* CSS or Java. When you want to do something more complicated, the syntax and semantics scale beautifully: (element water-molecule (make molecule hydrogen: 2 oxygen: 1 (if (equal? (attribute-string "HEAVY")) (make label (literal "HEAVY WATER")) (make label (literal "LIGHT WATER"))))) I know that this is not really what CML is all about, but it just shows that flow objects don't really need to be traditional layout-oriented style objects. It is up to the browser or whatever to attach whatever semantics it wants to them. The DSSSL language just allows the transformation from arbitrary structure to fixed semantics. Of course you should still use Java under the covers, but DSSSL offers an elegant, scalable user interface to your hairy, "Object Oriented" Java code that chemists are probably not interested in getting into. Note that when I wanted to do something simple like change an output label based on an input attribute that I did not have to declare any classes, or assign to any variables as I would have had to in Java. Java is great for building browsers and other systems, DSSSL is better for building declarative specifications that may need to scale into complex expressions or even full programs. Paul Prescod
Received on Thursday, 27 March 1997 11:56:26 UTC