Re: xsl 2.0?

Thanks for this Tony, and especially for the mention of the Print and Page
Layout Community Group.

The idea of a more modular spec is appealing if it means that a more modular
implementation can be built and tested piecemeal. I haven't had a look for
many years now, but the 1.0 spec was a nightmare. There were, necessarily,
complex interactions buried across scattered elements of the spec; and these
interactions were poorly understood by its writers.

This is not to say that the spec isn't a virtuoso display of print layout
expertise - it is. But the domain is so complex that problems were inevitable.
I imagine there are still plenty of edge cases where mature commercial FO
processors are incompatible, and the requirement for compatibility is going to
be a major hurdle to surgery on the spec.

Peter West

"...for everyone who exalts himself will be humbled, but he who humbles
himself will be exalted.

On 5 Nov 2013, at 1:27 am, Tony Graham <tgraham@xxxxxxxxxx> wrote:

> On Sun, November 3, 2013 4:41 pm, G. Ken Holman wrote:
>> At 2013-11-02 16:23 +0900, Toshihiko Makita wrote:
>>> 3. I beleive that XSL-FO is most suitable techinology for formatting
>>> XML documents.
>>
>> Agreed.  My customers are getting real-world problems solved with XSL-FO
>> 1.1.
>
> It's one of those things where the answer if different for different
> people.  I've had more approaches for XSL-FO work in the last 18 months
> than in any similar period previously, so, yes, it's working for many
> people, including people new to XSL-FO, yet the volume of messages on
> www-xsl-fo is at the lowest that it's ever been [1], so it's hard to see
> that the number of developers is growing, so other people are looking
> elsewhere to solve their real-world problems.
>
> Again, whether it solves enough real-world problems depends on which world
> you live in.  IIRC, Peter Flynn will happily describe XSL-FO as being only
> good for office documents (meaning, for Peter, that it's not as good as
> TeX), and it didn't take long for people at the Print and Page Layout
> Community Group to come up with some unsatisfied requirements of their own
> [2], yet Bert Bos in his "Can you typeset a book with CSS?" [3]
> presentation at the "eBooks & i18n" workshop in Tokyo shows a mathematical
> formula in a running header that is simple in XSL-FO (with MathML support
> in the XSL-FO formatter) but impossible in CSS as it stands, and Dave
> Cramer in his "The Exotic World of Trade Publishing" [4] presentation
> shows the lengths he has to go to to get a running title, a dingbat, and
> the page number as the running header, which, again, is simple in XSL-FO.
>
> The problem for XSL-FO is that it looks like the CSS users will get their
> problems solved in a standard and interoperable way sooner than the XSL-FO
> users will theirs.
>
>> I think the few things that are needed and are found (or not) in some
>> vendor extensions would be good fodder for an XSL-FO 1.2 rather than
>> an XSL-FO 2.0 (e.g. line numbering, repeating sets of page master
>> references, more page-position testing options, etc.).
>
> It hardly matters whether the next step is XSL-FO 1.2 or XSL-FO 2.0 when
> there's no Working Group to bless it and no commitment from vendors to
> join a Working Group or to implement any common scheme, since you need
> interoperable implementations to get a spec to Rec.
>
> In the absence of a Working Group, the next best place to work on a spec
> is a W3C Community Group [5].  The Print and Page Layout Community Group
> [6], to my mind at least, isn't solely about XSL-FO (or even solely about
> XML) but it does have permission to host and modify its own version of the
> XSL-FO 2.0 spec [7].  There is a long outstanding action item to put the
> source up on the CG's Mercurial repository, but so far no-one's tapped me
> on the shoulder to follow up on why it hasn't been done yet.
>
> The Print and Page Layout CG has also considered making a version of the
> spec that's more modular [9] so that improvements aren't all-or-nothing.
>
>> I also think the features of XSL-FO 1.x are going to continue to
>> satisfy high-volume or highly-repetitive print requirements for a
>> very long time.
>
> It can satisfy many requirements for high-volume or highly-repetitive
> print, but Klaas Bals of Inventive Designers was the editor of the 2.0
> requirements document [8], and Inventive Designers's customers produce
> documents in jaw-dropping quantities, so I think that it's fair to say
> that XSL-FO 1.1 doesn't satisfy all requirements for high-volume or
> highly-repetitive print.
>
>> Of course I'm not trying to devalue the work those working on XSL-FO
>> 2.x are creating to meet client requirements of theirs that demand
>
> Thank you (on behalf of many people), but at this point it's "who worked",
> and once the requirements document was agreed upon and published, it was a
> matter of working to meet the published requirements, not looking to
> satisfy any clients.  Who, for example, would you count as Liam's clients?
>
>> the changes needed ... I'm just not seeing anything major that has to
>> change for me to do my job.
>
> Which is a good thing, though I think we agree that other people have
> other requirements.
>
> Of course, part of the problem for XSL-FO is that there's unlikely to be
> anybody who desperately wants everything that's in the XSL-FO 2.0
> requirements document, but various needs for various parts of it hasn't
> translated into a strong push from many users for vendors to implement it.
>
>>> Does CSS techinology become the complete alternative of the XSL-FO?
>>
>> I don't think so, but then again, I haven't been following CSS very
>> closely since XSL-FO 1.1 has been meeting my client's expectations.
>
> I do follow it, and CSS for pagination is in a strange place right now
> since the two pagination-related specs are having a holiday [10] in a
> stranger place [11].  Discussion often centers around what can be done by
> the two main implementations, but given the way CSS can specify things in
> successive 'levels', the CSS folks can -- once they have the details
> specced and interoperable -- codify that as 'level 1' then move on to
> bigger and better things as 'level 2'.
>
> As other people have said in this thread, it's not so much a question of
> whether CSS can become the complete alternative to XSL-FO but whether CSS
> can become a good enough alternative to XSL-FO for enough people.  E.g., I
> have some stuff that I do with deciding if a table should be column-wide,
> page-wide, or rotated based on its formatted size [12] that I can't see
> CSS doing in a hurry because it requires multiple passes through the
> formatter (though with the future addition of JavaScript inside a CSS
> pagination engine, I'm no longer so sure), but there's a lot of stuff
> today for which CSS is good enough and there's likely to be more in the
> future.
>
> I don't see XSL-FO and CSS as either/or, us/them, saints/sinners, or any
> other dichotomy.  I'm happy to help both advance so I can produce better
> output, but at this point XSL-FO doesn't have enough people working on it
> for it to be able to advance.
>
> Regards,
>
>
> Tony Graham                                   tgraham@xxxxxxxxxx
> Consultant                                 http://www.mentea.net
> Mentea       13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
> --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
>    XML, XSL-FO and XSLT consulting, training and programming
>       Chair, Print and Page Layout Community Group @ W3C
>
> [1]
>
http://markmail.org/search/?q=www-xsl-fo#query:www-xsl-fo%20order%3Adate-forw
ard+page:1+state:facets
> [2] http://www.w3.org/community/ppl/wiki/CustomerRequirements
> [3] http://www.w3.org/Talks/2013/0604-CSS-Tokyo/, slide 10
> [4]
>
http://www.w3.org/2012/12/global-publisher/slides/Day2/P1-w3c-paris-hachette.
pdf,
> pages 38 and 39
> [5] http://www.w3.org/community/
> [6] http://www.w3.org/community/ppl/
> [7] http://lists.w3.org/Archives/Public/public-ppl/2013Feb/0046.html
> [8] http://www.w3.org/TR/xslfo20-req/
> [9] http://lists.w3.org/Archives/Public/public-ppl/2013Mar/0000.html
> [10] http://lists.w3.org/Archives/Public/www-style/2013Oct/0460.html
> [11] http://blog.whatwg.org/css-books-css-figures
> [12]
>
http://www.balisage.net/Proceedings/vol10/html/Graham01/BalisageVol10-Graham0
1.html#d44854e105