XSL FO how to make things go. Re: Q: XML+XSL transforms to a print-ready format

["Paul Tchistopolskii" <paul@xxxxxxx>]

From: James Tauber 
Sent: Sunday, October 10, 1999 6:25 PM
Subject: Re: foo ... bar Re: Q: XML+XSL transforms to a print-ready format


> >From Paul's last reply to me, I think Paul and I have now phrased things in
> such a way that we agree with each other. I suspect we really did all along.

Not completely. ;-) I see more than one way to workaround 
"running heads" on the level of FOs  and I'm not sure that 
I'l like to solve that particular problem instead of  inveting the 
more general layer.  After Sebastian will provide us with the 
usecase - the renderx will definately start rendering it, trying 
to design the most elegant approach. Of course, if we could 
have your approach before inveting our own it could be  
much better scenario, but it is not necessary. 

Unfortunately, the biggest problem I ( and not only I) see 
here is W3C silence. If they will just say that : "we'l place 
it into next version of WD coming tomorrow" - why should I 
start inveting the things that are to be solved by some 
professional designers anyway?

If W3C says: "we'l postpone it until the version 2  (it is approx. 
the end of next year)" - no problem again - I *should* invent it 
right now. 

Unfortunately, if  there is a silence about scheduling , the 
best thing I see may  be to start with 'parallel'  XSL WG  when 
all of us implementing the XSL FO theme would start sharing 
our ideas and approaches ( exactly like XSL WG  is doing it ).
Such a strange world ...

We already have a kind of  'parallel' XSL WG in renderx. A group of 
people reading the WD and making attempts to move forward 
without killing too much consistency. Given that we are 
doing it in the isolation  ( and of course not all of us have 
the appropriate expereince ) - the results may be sometimes 
crazy ( ... however, the WD is anyway strange in some places ...). 

I'm sure that if we expand our group so that some other 
XSL FO implementators will provide their suggestions we'l 
get much better picture.

On another hand, creating parallel XSL WG from implemetators
only is also not the best possible thing, because implementators 
may start concentrating on some local aspects.

So the best  way is to work out the reasonable W3C
process that will make things  better for designers *and*
implementators as well. It was the issue I raised in XML-dev 
list long time ago. The current W3C processes may cause 
the 'Linux' of XML.

The discussion around "running heads" is the perfect illustration, 
of what I mean. It may easy happen that we'l have yours, Sebastian's 
and renderx approaches. All different. Firstly at the level of XSL FOs.

Then we may get  the same with other parts of XML. 

> The open issue is the interaction between user requirements, the scope of
> the spec and what an implementation actually does. I think this is an issue
> that extends well beyond XSL to standards-based development generally.

Exactly. It's the business of  W3C, right? 

> > The only question for me is now why should not I do it in the
> > proprietary way?
 
> Well, you don't have a choice. You *have* to do it a proprietary way because
> there is no standard way. Perhaps if you, Sebastian and I implement it the
> *same* way it won't be so bad.

There is always some choice. For example there are more than three of us 
who are trying to produce some reasonable version of FOs. For example, 
Steve's questions shows that some people who did not yet announced 
their implementations are realy doing some very intersting things ;-)
 
I think some kind of realistic process which will allow those who are 
involved in implementation to cooperate closely with those who are 
involved in the design may benefit everybody ( and poor uses as well ).

Actualy, I'l be almost glad if it'l result in the situation when all of 
XSL FO implementators will start publishing their RFCs, share the 
testcases and results of rendering  - maybe create the XSL FO 
portal e t.c. 

Yes, with  each implementator implementing it's own 'spacer' tag
it is obviosly the easiest  approach. I just hope we'l not get to 
this situation. Maybe I'm too idealistic. Obviosly - I was.

On another hand, because  I respect  you, Sebastian and many 
other XSL-list  and/or  WG participarors - if there will be any initiative 
to join the  efforts and / or resources  to improve the situation 
with  XSL FO - I'l try to do all I can do to make renderx to join such 
initiative, even it'l require us to spend some more resources for 
that activity.

Rgds.Paul.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 paul@xxxxxxxxx   www.renderx.com   www.pault.com
 XMLTube * Perl/JavaConnector * PerlApplicationServer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list