Re: [xsl] xsl 2.0?

["Tony Graham" <tgraham@xxxxxxxxxx>]

On Wed, November 6, 2013 3:36 pm, Wendell Piez wrote:
> 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.

Not exactly, possibly even not at all.  The 'Introduction' section of the
next level of Selectors [1] (no longer called 'CSS Selectors', BTW, and
explicitly for 'HTML and XML') includes:

   applied to an entire tree of elements to filter it into a set
   of elements that match the criteria, such as in the
   document.findAll() function

and the first/main point of the jQuery library is using CSS selectors to
find things.

As for less complex, try these, that I'm almost glad we haven't had to
deal with with XPath:

 - E:future - an E element that is in the future in a
   time-dimensional canvas

 - E:invalid-drop - an E element that cannot receive the item
   currently being dragged, but could receive some other item

OTOH, Jirka Kosek is having an uphill battle trying to persuade enough of
the CSS WG that Selectors 4 should be able to select attributes as well
[2], and the last slide in Dave Cramer's talk [3] at the "Publishing and
the Open Web Platform" workshop calls for "XPath-strength CSS selectors".

...
> 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.

My position paper for the same workshop [5] called out the need for the
Open Web Platform to include a declarative transformation language as an
alternative to using JavaScript, but I was also sceptical that the OWP
would just embrace XSLT.

I keep mentioning the "Publishing and the Open Web Platform" workshop
because it's a recent snapshot of what people are doing in publishing, and
I found it interesting (and contrary to my position paper) that several
publishers there (including O'Reilly, who champion no-markup authoring
[8]) were using XSLT to transform XHTML to XHTML to target different
devices, meaning they could easily produce the 'ToC' as well as the
'manifest' for their EPUBs along the way using XSLT.

> 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

It's been years, even decades, since web browsers have sliced across lines
of text to make a page break, and for many people, what we have now is
good enough.  For example, Adam Hyde in his position paper [6] argues that
book production is possible now using HTML and CSS (though the widow on
his second page undermines his position).

...
> 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

The terminology (largely, I think, because Liam repeats it in lots of
presentations) is veering towards [7]:

 - XML First, in which the authors supply XML;

 - XML Early, in which the authors and copy editors work with
   Microsoft Word and its revision tracking before conversion
   to XML;

 - XML Late, in which paginated PDF (or InDesign documents) are
   sent out of house and converted to XML;

 - XML Never, or the traditional workflow in which Quark or
   InDesign is used to produce PDF for print, and electronic
   books are not created, or are static PDF copies of the
   printed books

so, as with many things, different people come up with different answers
to the same question.

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://dev.w3.org/csswg/selectors/
[2] http://lists.w3.org/Archives/Public/www-style/2013Nov/thread.html
[3]
http://www.w3.org/2012/12/global-publisher/slides/Day2/P1-w3c-paris-hachette.pdf
[4] http://www.w3.org/2012/12/global-publisher/
[5]
http://www.w3.org/2012/12/global-publisher/statements-of-interest/17-tony-graham-mentea.pdf
[6]
http://www.w3.org/2012/12/global-publisher/statements-of-interest/02-workflow_adam_hyde.pdf
[7] http://www.w3.org/2012/12/global-publisher/report.html
[8] http://www.w3.org/2012/12/global-publisher/slides/Day1/P0-witwer_adam.pdf