[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] xsl 2.0?


Subject: Re: [xsl] xsl 2.0?
From: Paul Tyson <phtyson@xxxxxxxxxxxxx>
Date: Mon, 04 Nov 2013 23:01:58 -0600

I appreciate all the various comments on my original post. I'm afraid
Michael has summed it up most accurately.

On Mon, 2013-11-04 at 10:45 +0000, Michael Kay wrote:
> It's a very common thing in our industry that a simple spec with many
>  limitations becomes dominant despite the existence of a better spec
>  with more features designed to meet "high-end" requirements. Just look
>  at rfc-822 compared with x.400 email for an example. Of course some of
>  the better features of the "complex" spec end up migrating into the
>  "simple" spec, which in turn has the effect of further reducing the
>  number of people who need the features of the "complex" spec. 
> 
> What we seem to be seeing here is that the community that requires
>  XSL-FO doesn't have the resources to ensure its continued development.
>  Arguments about why XSL-FO is better than CSS aren't going to change
>  that.

Agreed. Indeed, my hope for XSL-FO is that it grow to be more of the
DSSSL replacement it was originally intended to be. That, unfortunately,
is in the direction of greater complexity.

As I was casting about for a suitable framework for applying
presentational semantics to linked data, I was led--unexpectedly--to the
DSSSL style language. Since DSSSL is probably not a viable option in my
application, I looked to the current state of XSL-FO, hoping that 2.0
might have come along far enough to do duty, and was disappointed to see
that it too had been abandoned.

Quoting from DSSSL 12.2: "A flow object tree is an abstract
representation of the merger of the formatting specification and the
source document."

XSL-FO dropped the "abstract representation" part of that, and deals
only with syntactic "formatting objects" instead of abstract "flow
objects". While this was a useful simplification that supported a wide
range of formatting needs, it falls short of the capabilities specified
by DSSSL.

I found that I needed something like the beloved DSSSL style language
"sosofos"--specifications of a sequence of flow objects. Quoting again
from DSSSL (12.4.3 note 50): "The expression language never operates on
flow objects directly; it only operates on their specifications using
the sosofo data type."

This is exactly the capability you need to specify the formatting of
data that has been derived by applying arbitrary queries to RDF
repositories (which, incidentally, is not too unlike the "grove"
abstract formalism underlying DSSSL).

Specifically, what I hoped to find in XSL 2.0 was support for complex
page layout and flow mapping to multiple regions. It would also be good
to extend the formatting object vocabulary and properties to accommodate
all the interactive and multi-media capabilities of HTML5 (at a
minimum). This would allow specification of these features without
prejudice toward a particular delivery channel.

In the meanwhile I think I can use some of the proposed XSL2 vocabulary
for complex pages, and namespace extensions for my other requirements.

I do believe, however, that it would advance the art to revive and
complete XSL 2.0 along these lines. Maybe the trend away from
proprietary formatting systems will tip the scales back in favor of
improving XSL-FO.

Regards,
--Paul


Current Thread
Keywords
xsl