Subject: XSL FO how to make things go. Re: Q: XML+XSL transforms to a print-ready format
From: "Paul Tchistopolskii" <paul@xxxxxxx>
Date: Sun, 10 Oct 1999 20:42:14 -0700
|
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
|