Re: XML Conformance Levels [Was: ERB Decisions of March 26th]
I don't want to create an unnecessary discussion - my main concern was to
put down a marker for an XML processor which could ignore STYLE. It may well
be a minority interest and so I won't labour it. However, since I seem to be
portraying Scheme and DSSSL to be harder than they are, I'll make a few points
and then shut up :-)
In message <199703271508.JAA11655@copsol.com> email@example.com (Alex Milowski) writes:
> > I choose to use TEI for that because:
> > - I understand it (unlike DSSSL)
> Yes, but DSSSL needs introductory material. If the SGML standard is not a
> resource for beginners in SGML, it is certainly not for beginners DSSSL--even
> for experienced SGML people. Hence, give it a chance once you get ahold
> of introductory materials.
The first question I have to answer is whether I need DSSSL. If I don't, then
I can't take the time to learn it; If I do, then I have to know how much time
I need to find out :-)
> > (c) I have no obvious need for DSSSL. There are several reasons:
> > - it will take me 2-3 months to understand it and see if Kawa or
> > similar is useful to me. (Scheme is a non-starter, sorry)
> I not certain how Kawa plays into it, but I will say that it supports both
> DSSSL quantities and DSSSL lambda procedures with keywords. Thus, in some
> ways, it is built to implement DSSSL. We can all thank Per Bothner at
> Cygnus for this.
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.
> > - 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
> > - 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.
> CSS means I potentially can deliver SGML/XML to a standard web browser now.
> It also means, I can't go as far as I need for some clients.
> I have people who absolutely *need* to deliver print documents over the net. It
> would be very nice to deliver a stylesheet that does that for them.
> Unfortunately, we have to do the formatting on the server and send them
> something like RTF or PostScript (preferrable the latter).
I have no problem about this as (correctly) the majority interest :-).
> The other problem with CSS is the assumption that element equals style. In
> cases where style presentation is not a isomorphic relationship (that is
> one-to-one and onto--a direct mapping), you can accomplish the style in CSS.
> The "element equals style" concept can be severly limiting. It also may work
> just fine for your application.
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.
> 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
> > (c1) I believe we can solve our 'style' problems by supplying methods attached
> > to elements/objects. I may well be wrong, but it works so far. For example,
> > I have taken Jon's PLAY and hacked a very few classes which render it
> > appropriate styles. Thus there is a PERSONA class which draws a little icon
> > and changes the font. Where appropriate it uses TEI notation to identify
> > components to process. I doubt there is much more code than DSSSL equivalent.
> This can be done quite easily in a DSSSL system. We do this now with our
> product. Every flowobject definition is dynamically loaded via class loaders
> in Java. Thus, definitions and semantics can be loaded dynamically.
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
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences