Re: [xsl] xsl 2.0?

["Kevin Brown" <kevin@xxxxxxxxxxx>]

***Disclamer --- those that know me know I speak my mind, sometimes too
overtly, but ***

I just love this comment:

> (though the widow on his second page undermines his position).

Of course it does.

But I am sure I am wrong and of course CSS is ready for all

(or least those who are happy with print-screen as "high-quality print")

Kevin Brown
RenderX




-----Original Message-----
From: xsl-list-digest-help@xxxxxxxxxxxxxxxxxxxxxx
[mailto:xsl-list-digest-help@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Monday, November 11, 2013 10:10 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: xsl-list Digest 12 Nov 2013 06:10:00 -0000 Issue 3245

xsl-list Digest 12 Nov 2013 06:10:00 -0000 Issue 3245

Topics (messages 65031 through 65032):

Re: xsl 2.0?
	65031 by: Tony Graham
	65032 by: Kerry, Richard

Administrivia:

To subscribe to the digest, e-mail:
	<xsl-list-digest-subscribe@xxxxxxxxxxxxxxxxxxxxxx>

To unsubscribe from the digest, e-mail:
	<xsl-list-digest-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx>

To post to the list, e-mail:
	<xsl-list@xxxxxxxxxxxxxxxxxxxxxx>


----------------------------------------------------------------------
Date: Mon, 11 Nov 2013 09:54:14 -0000 (GMT)
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
From: "Tony Graham" <tgraham@xxxxxxxxxx>
Subject: Re: [xsl] xsl 2.0?
Message-ID:
<58453.83.147.131.233.1384163654.squirrel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>

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-gr
aham-mentea.pdf
[6]
http://www.w3.org/2012/12/global-publisher/statements-of-interest/02-workflo
w_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

------------------------------

Date: Mon, 11 Nov 2013 10:07:37 +0000
To: "xsl-list@xxxxxxxxxxxxxxxxxxxxxx" <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
From: "Kerry, Richard" <richard.kerry@xxxxxxxx>
Subject: RE: [xsl] xsl 2.0?
Message-ID:
<61C67DC73308BD49B2D4B65072480DBA23022FFA@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ns.net>

Might it be the case that some persons who could make use of XSL-FO, as opp=
osed to CSS (*), are unaware of its existence ?
=20
I think CSS is very well known (**) among all who do any work containing an=
y element of Web Design.  However many of them have picked up their knowled=
ge ad hoc and not been formally taught.  Hence may also not have been requi=
red to learn about other technologies in the area, such as XSL-FO.
=20
=20
=20
Regards,
Richard.
=20
=20
=20
(*)
I.e. as an improvement on CSS, providing features that CSS can't do, or do =
easily.
(**)
I mean its existence is well known, not that it is necessarily understood i=
n detail.  Many users may only use it in a limited way.

Richard Kerry
BNCS Engineer, SI SOL Telco & Media Vertical Practice

T: +44 (0)20 3618 2669=20
M: +44 (0)7812 325518
Lync: +44 (0) 20 3618 0778
Room G300, Stadium House, Wood Lane, London, W12 7TA richard.kerry@xxxxxxxx
=20
=20

------------------------------

End of xsl-list Digest
***********************************