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.
Sounds quite reasonable to me! :-)
> > > - our community will take years to write in it.
> > I don't understand. Are you saying it will take *years* to write stylesheets?
> 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.
Transformation are part of DSSSL as well. ...but they are a different part of
the standard. What does "discipline-relevant" mean?
> > > - they think that plugins and CSS will solve their problems anyway
> > Some, maybe, but it doesn't scale. I'm both excite and disappointed
> > about CSS.
> This is only a small number anyway. Most of them will probably not have
> encountered stylesheets or will use them for simple font manipulation.
> [BTW I don't want to seem arrogant. The problem is that documents are not
> seen as exciting, but data are. Therefore people still write one-off programs
> to hack data.] So the typical activities are EITHER:
> - download some html, and display it
> - download some data and crunch it.
> If the html 'contains data' download it as a legacy file and write a one-off
> plugin to tweak it a bit.
The 'data crunching' seems to be what the transformation side of DSSSL is for.
Right now, I don't think there is sufficient momentum to get transformations
into XML. I'd like to see that happen some day...
> > Note: Any CSS people can correct me if I'm completely off my rocker.
> > > - it offers no functionality *after* parsing (or at least after
> > > rendering) as far as I can see.
> > What do you mean? After parsing?
> 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
No. This is a common misconception about DSSSL. The result of applying a
DSSSL stylesheet is a flowobject tree (or event stream as in Jade--an
equivalent construct). A flowobject is a "thing" that has properties. Thus,
if your application flowobject has a "mouse-up" property, you can specify
what to do with that property.
In DSSSL you need to separate the description of the data of the behavior
(e.g. what value my "mouse-up" property has) from the use of that
data (e.g. on a mouse up, take the image specified in the property value and
display it). Formatting is just one kind of style semantic. Browser
display semantics is another--and this is what you seem to be interested in.
Once the flowobject has be built, something needs to supply semantics for
making it *do something*. In jade, this is what the backends are for. In
my DSSSL environment, that is what an exterior or interior does.
For an example from HTML, in DSSSL I could say:
;; a quick example (not complete)
(let ((name (attribute-string "NAME" (current-node))))
;; check to see if the name has been specified
;; make an anchor for a fragment
;; other properties)
;; make a link to an HREF
target: (attribute-string "HREF" (current-node))
mouse-over: (attribute-string "ONMOUSEOVER" (current-node))
;; other properties here)
This would be a way to transfer the data of an HTML anchor element to one
of two custom flowobject. Now, there is a "link" flowobject in DSSSL, but this
certainly doesn't have a mouse-up property.
Note: There are many ways of doing the above.
R. Alexander Milowski http://www.copsol.com/ firstname.lastname@example.org
Copernican Solutions Incorporated (612) 379 - 3608