Re: XML Conformance Levels [Was: ERB Decisions of March 26th]
> 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
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))
(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
(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.