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

Re: [xsl] xsl 2.0?

---

---

Hi,

On Tue, Nov 5, 2013 at 6:06 PM, Tony Graham <tgraham@xxxxxxxxxx> wrote:
> So XPath -- or the possible complexity of the XPath needed to match or
> select just the right thing -- is a problem?

Yes, I think it is. Two things about XPath:

1. It works over a data model that is not explicit, but must be
learned and then inferred from syntax, not read directly. This is
especially true of XPath 2.0 but it's even true of XPath 1.0.

This is true of CSS also, but the data model is (at least for
practical purposes) less complex and more amenable to fudging. In part
this is because CSS selectors only need (something like) XSLT @match
semantics, not @select.

2. XPath is simple enough for simple things, but this simplicity is,
in part, a ruse, to the extent that it results only from syntactic
optimization (the "short syntax"). This aspect of its design gives
with one hand, while it takes away with the other, since beginners can
make things work only until the moment that they can't. There's a big
fall-off between the shallow end and the deep end.

To mitigate this, I have had success teaching XPath to "non-technical"
users (e.g. professional librarians, who are actually very technical
in their own way) by having them work entirely in the long syntax
until they're comfortable with it, and only then showing them the
abbreviations. Some of these students have even stated, at the end,
that they prefer the long syntax in any case: it's explicit.

I should stress that both these weaknesses are aspects of XPath that
come with its strengths. The XPath data model is capable and
versatile, despite (in some respects because of) its hybrid nature.
And I like and use short syntax except when a customer asks that I
don't (this has happened too).

> For XSLT, when you can do practically anything inside a template, and do
> it multiple times with modes, it would become hard to simplify that behind
> a GUI.  Conversely, if you do have to simplify things to make a wizard
> GUI, if you then need more you're either stuck or you edit the template in
> ways that are no longer GUIable (assuming there is such a word).
>
> There are GUI frontends for editing stylesheets, but none of them have
> been runaway successes AFAICT.  I do sometimes wonder why we still mostly
> write stylesheets by hand as XML, but none of the various efforts at a
> 'compact syntax' for XSLT have had much success either.
>
> CSS became a lot more tractable (IMO) with the availability of tools like
> Firebug that let you see the styles that apply to a particular element and
> even modify them in-place in the browser.  I haven't seen anything similar
> for XSL-FO.  Oxygen's debugger output is pretty good for seeing where an
> element or attribute in the result came from, but you can't then modify
> the stylesheet and see the change ripple through the output without
> running the debugger again.  Antenna House's Windows GUI will show you
> text properties but not margins, borders, etc., and again you can't modify
> them in place to see what would happen so, if you're like me, you end up
> editing an FO file and refreshing it in the GUI to see what changed.

I agree with Tony that the development of really interactive
development environments for CSS has been a huge help. Of course, this
is largely possible because CSS is limited to formatting semantics,
which by definition can be displayed.

Consider this processing rule: Where the document has an empty 'div'
element with [class~=toc], substitute for it a nested list collecting
all the h1|h2|h3|h4 elements that are the first children of their
containing divs (the nesting of the list corresponding to any nesting
of the divs), show them as items, and display the list with formatting
properties X, Y and Z. Make each of the list items in the list a link
to their 'div' elements in the source (where the links are not
explicitly coded).

Suddenly a GUI has become significantly harder. Indeed, a web
developer coding this in Javascript has to visualize the process in
her head in the same way an XSLT developer does. A debugging
environment can help, but we have those for XSLT too.

Arbitrary transformations aside, this also bears on the question of
XSL-FO because the base-line production values of print (as Tony well
knows :-) even at the rudimentary level of XSL 1.0 (what Peter calls
"office documents") are significantly more challenging to automate
than those of web browsers -- which, in 2013, even after 20 years of
painful advance, are only a vague hint of what they ought to be and
should eventually be. The semantics of HTML5 and CSS3 represent steps
(or maybe lurches) in the right direction but see what it has taken us
to get even this far -- and this direction is not really towards the
high standards of print, but divergent, towards a different set of
requirements, for interactive displays on computing devices. One
consequence of this evolution is that the web of today is a very far
cry from the ideals of 1993, when "anyone" could implement a web
browser. Even the idea that anyone can learn to be a web site
developer without professional training or apprenticing may now be a
myth. And yet web developers are also called on to be experts in print
layout, typography and production.

Then too, there is an elephant in the room: what happens when a
workflow devoted to achieving good results in print collides with a
workflow oriented towards online media. The old ideal of "single
source, multiple outputs" may only be fully achievable, practically,
in systems where the different outputs can be carefully aligned, and
this means processes that are centered in editorial policy (defining
what we used to call an abstract "document type" but now might take
the form of an application profile of XML or HTML/CSS), with both
authors and designers subordinate to editors. Where this alignment has
not been (and maybe cannot be) achieved, we have a huge amount of
confusion, thrashing, and compromise. Good tools for production,
whether HTML/CSS IDEs or Adobe InDesign, do not help this problem; in
fact sometimes they exacerbate it by encouraging people to mistake
what they are looking at.

Cheers, Wendell

Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

---