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> lex@www.copsol.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 :-)

>   
> <snip>
> 
> > (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 
discipline-relevant manner.  
> 
> > 	- 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
OR
	- 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 
processing.

> 
> > (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 
demonstrators working.

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

Received on Thursday, 27 March 1997 10:59:25 UTC