My response to Leventhal's article...

[Stephen Deach <sdeach@xxxxxxxxx>]

This was posted to XML.com earlier today...

----------------------------------------------------------
As a member of the XSL working group and having worked in the computer
industry for over 20 years on a broad spectrum of products to author,
format, and render communications vehicles of many kinds, (word processors;
DTP applications; commercial newspaper, magazine, directory, catalog, and
advertising production tools; slide show authoring; data base and document
management systems; web site authoring; photo image editing and retouching;
charting, illustration and engineering graphics; font creation and
rendering; and the internal software in typesetters and printers, etc.),
some making extensive use of structured content and stylesheets and some
making little or no use of stylesheets, I certainly qualify as an expert in
document modeling, content editing, styling, and formatting tools. I have
seen debates of this nature many times and prefer to ignore them, as they
usually blow over. In this case, due to the timing and the stridence of his
statements, I feel it is necessary to respond with my personal opinions on
Mr. Leventhal?s so-called challenge. I further feel that it is necessary to
respond because he makes a series of claims (which I believe to be false)
and then directs you to reach the same conclusions and so vote.

I must at this point, for legal reasons, re-emphasize that these are my own
opinions and not necessarily those of the XSL-WG nor necessarily those of
my employer.

The timing of his challenge is inappropriate because XSL is still a working
draft, yet he claims XSL is deficient because: 
a.) XSL is a future technology
Response: This is what a working draft is, by definition, a future
technology. Every technology goes through this phase. 
b.) The specification is in flux and there is significant change from draft
to draft
Response: Keeping the public informed about the current state of the W3C?s
efforts, making the rate of change and degree of change visible to the
public is exactly W3C?s goal in requiring the publication of working drafts. 
c.) Only limited preliminary tools to use it exist
Response: but tools do exist and the users of these tools have provided
substantive feedback that has lead to improvements in XSL. 
d.) Those tools are incomplete or don?t implement the latest version of the
draft
Response: gain, exactly what one would expect as a specification evolves.

The terms of the challenge are extremely vague, they can be tailored so
that both sides could declare victory. The outcome of a challenge whose 2
criteria for measurement "better" and meaningful" is guaranteed to be
indeterminate. Both terms can only be measured "in the eye of the beholder".

A number of claims are made about the value of XSL on the web. Many of
these claims are either false or they completely miss the point.

Claim 1.) Interactivity is a requirement for a technology to be useful on
the web.
Response: This is completely false. The vast majority of web sites are
essentially static. Interactivity, beyond traversal/addressing and some
level of data-entry (form fill-in) has little value for a huge class of
meaningful sites/documents.

Claim 2.) XSL precludes interactivity. -- No more so than CSS.

Claim 3.) Print has no place on the web.
Response: This issue has been discussed extensively in the XML.com mail
forum and on the mulberrytech.com?s xsl-list (public comment list for XSL).
The fundamental responses have been:
a.) For a large number of people, print is important. The web is as much
about formerly paper-only documents and print-on-demand as it is about
interactive and animated ones. 
b.) Paged composition is not significantly more computationally intensive
than browser formatting. 
c.) Paged views (fit to the window and/or page) are extremely useful for
some content. 
d.) Claims that the market for repurposing is a handful do not explain the
robust attendance in these sessions at Seybold Seminars and other
conferences for the past 3 years. 
e.) Though one could create separate stylesheets in CSS for viewers, XSL
for print-on-demand, PDF for critical print, etc. I don?t want to if I?m
not forced to. The training cost and error rate is unacceptable.

Claim 4.) XSL is a danger because it removes semantic meaning.
Response: XSL allows you to preserve the semantic meaning of your XML by
not polluting the XML with presentation (as happens in HTML and in HTML+CSS
today with semantic-free divs & spans and with the widespread misuse of the
remaining tags). 

Claim 5.) FOs are bad
Response: A related FUD issue to the claim that they remove semantic
meaning. This issue originated in a paper posted by Mr. Lie (and referenced
by Mr. Leventhal). You should also look at the archives of the
mulberrytech.com?s xsl-list to evaluate the response to Mr. Lie?s paper and
e-mails. Many of his key points were disputed or discredited.

I refer you also to James Tauber?s response to this issue: CSS tags ARE
formatting objects. The ?display? property identifies the fundamental
formatting behavior of the element, this is exactly what an XSL-FO does. I
would add: XSL-FOs are simply more general (cover a broader scope), and
defined in a manner that has fewer side-effects (interdependencies). If
anything, CSS is the "supercharged FONT tag", XSL at least
compartmentalizes the side effects.

Claim 6.) XSL gives me nothing new
Response: There is a huge class of documents that are not made available on
the web, because either formatting/pagination is inadequate using existing
standards, or because they must be broken into little sub-documents for
presentation. XSL gives me a much more convenient and format-rich way to
transition this broad class of paper documents to the web. XSL also makes
it easier to build stylesheets for those documents that need to be authored
for both online and print media (including print-on-demand).

In this class of documents I would include: any document used in a business
transaction or legal context (including proposals, requirements documents,
contracts, court filings, insurance policies, tax documents, safety
notices, forms); any document used in a design or manufacturing context
(design and manufacturing specifications); any document used in a service,
customer relations or customer support context (various types of manuals,
instructional inserts); any document used in promotional context (catalogs,
e-catalogs, newsletters, brochures, and mailings); any document used in an
educational context (including textbooks); and the bastions of traditional
print (books/e-books, newspapers (?), magazines/e-zines). These documents
are meaningful because people either pay for them or pay to produce them.

Claim 7.) I can do all the formatting you can by adding a few minor tweaks
to CSS
Response: Anyone who has built more than one or two formatters (and I have
built over a dozen) recognizes that to add proper pagination and layout to
CSS requires quite a bit more than a few tweaks.

Claim 8.) Anything you can do in XSL, Mr. Leventhal claims he can do in
some combination of existing web standards: the DOM, CSS, and scripting
Response: One, not all the technologies referred to are web standards or
W3C Recommendations. Two, this misses a key point. As a programmer, Mr.
Leventhal can do anything. But most users aren?t programmers and vehemently
don?t want to become one. XSL can be built into tools that the web designer
or graphic artist can use, that are predictable and implementable. 

Claim 9.) XSL didn?t take into account anything learned from history (I
assume this means CSS)
Response: This is completely false. XSL had significant participation from
users and implementors of CSS as well as participation by a number of
members of the CSS WG, including the CSS&FP chair. In addition, the XSL WG
membership includes participants that worked on DSSSL and/or have
experience in building commercial formatting and authoring products that
averages 10+ years each. 

XSL includes all the formatting capability of CSS and nearly all the CSS
properties (verbatim). It similarly includes much of the capability of
DSSSL, in a more approachable manner. 

And no, XSL is not "DSSSL in sheep?s clothing". The XSL submission and
charter require the XSL WG to support the functionality of both CSS &
DSSSL. Well over half the effort of the group defining the XSL formatting
objects was to understand the full capabilities, the property interactions,
the discrepancies, and the limitations of BOTH these formatting languages,
then redefine the formatting model in a compatible manner. XSL fully
incorporates the formatting capability of CSS.

DSSSL was a well-thought-out solution to most of the problems that they
were trying to solve. That problem differs from XSL?s, hence DSSSL is not a
sufficient answer to the web formatting problem. 

The same can be said of CSS, it is a good solution for the problem that it
was originally intended to solve. However, attempting to extend it to solve
the range of problems that XSL is intended to address will make it an ugly
and unimplementable language. A different architecture is required to
support some of the extensibility that XSL requires.

As with any solution there are things one didn?t consider, mistakes that
are made, and features deferred to the next release. Because a solution
isn?t perfect doesn?t mean it isn?t useful. (If that were true, we should
ban HTML, CSS, XML, XSL, SGML, & every other W3C, ISO, ECMA, IETF, etc.
standard. None are perfect.)

Claim 10.) XSL is in competition with CSS.
Response: Most of the developers of XSL consider the 2 complementary, not
competing. CSS provides a convenient and workable mechanism for those
documents to which it is suited. XSL extends the market to documents and
styling requirements that are not well addressed by CSS. The W3C has
established a joint committee to maintain compatibility between XSL?s &
CSS?s formatting models and properties.

Claim 11.) XSL is hard
Response: Experience with the preliminary implementations of XSLT have
shown this to be untrue. For simple things, XSL is no harder than CSS. For
some of the more complex things (that one can?t do in CSS alone, it does
become more difficult, but it is less difficult than learning the DOM and
scripting for someone who doesn?t already know them or for someone who
isn?t a programmer.

Claim 12.) Scripting is more powerful than a declarative language
Response: This is true, as far as it goes. It also forces everyone to be a
programmer. XSL is a declarative language, not because declarative
languages are easier to use or more powerful, it is because declarative
languages are more implementable and more reliable. Having had firsthand
experience with PostScript (a procedural language) and PDF (a declarative
language) prior to joining Adobe, one finds that one gets only moderate
gains in the ease of authoring in the declarative language and that the
declarative language does have some limitations in capability. The biggest
gain in switching to a declarative language is in predictability and
reliability of the authored input (it can be validated) and in the ease of
developing correct implementations of the formatter.

I can always find a class of problems where a highly tailored solution is
cheaper than a general one (or where a specific programming language solves
a problem better than another language), however, this is not the true cost
of that solution. I must always ask:
a.) Does the general solution cover my problem space? If not use another
tool or a mixture of tools. (However, because it doesn?t meet this criteria
for your problems doesn?t mean it isn?t useful for mine.)
b.) Does it support my aggregate of problems at a lower cost than custom
tailored solutions to each individual problem. (However, because it doesn?t
meet this criteria for your problems doesn?t mean it isn?t useful for mine.) 
c.) If there is a significant subset of my problem space that can be
answered by a cheaper solution, shouldn?t I adopt it? (YES). If the
remaining problem space can?t be cost-effectively covered by the cheap
solution, shouldn?t I be allowed to solve the problem using a solution
appropriate to that problem space? (YES, if truly cost-effective) 

Claim 13.) XSL stands no chance of being accepted on the web. 
Response:  I don?t think this claim holds any water. IBM, Lotus, and
Microsoft have all announced support for XSLT. James Clark, Lotus and
Microsoft have released demonstration implementations. Several
implementations of formatting software have been announced and James Tauber
demonstrated his at WWW8 (two weeks after the latest Draft was available).
I think there is clear support for both the transformation and the
formatting components of XSL, and this is a fairly strong commitment for a
draft specification. The feedback these implementors and the WG are
receiving do NOT substantiate Mr. Leventhal?s claims. People find this
language useful, sufficient for most intended tasks, and understandable
(albeit non-trivial to learn). Improvements have been made to the
transformation language as a result of this substantive feedback."

Conclusion.) With every change in technology, there are a number of people
who have fallen in love with the status quo and attempt to derail the
evolving new technology. They say such things as: the new technology is
some pipe dream of the future, it is unproven, it is inefficient, it is
hard to learn and hard to use. It is a threat to what I know and love;
something new I am being forced to learn. -- On the new technology?s
inception, certainly all those things are true, but what happens in 2
years? What happened when people moved from FORTRAN to Pascal? from Pascal
to C? from C to C++? from proprietary printer/typesetter languages to
PostScript? from PostScript to PDF? from proprietary composition systems to
DTP? from ink, rubylith and darkrooms to Illustrator and Photoshop? The
same thing will happen to the web?s content and styling standards, the
technology that provides an answer to your problem will become the one that
you use. Some will fall to disuse, the remainder will live on and
complement each other.

Mr. Leventhal appears to be saying that the web world can not be allowed to
advance beyond what it has today. Nor does it appear that he would allow
the W3C to define alternate approaches to a problem or define new
approaches to problems that are not well served by existing W3C
Recommendations if there is any overlap between this alternate solution and
an existing Recommendation. Such a policy would be crippling to the future
growth of the web.

If XSL provides a better mechanism to support online presentation, it is
clearly in the web community?s interest. If it provides a better solution
to print it is clearly in the web community?s interest. If it provides a
common mechanism to support print and online presentation it is clearly in
the web community?s interest. If it does all of these, even better. 

>From preliminary indications, XSL seems implementable and useful, thus Mr.
Leventhal?s request to stop work on XSL (at least until CSS-2 is fully
implemented on every platform) is not only unrealistic, but is detrimental
to the web, since it would delay widespread support for XSL. 

One size does not fit all. If you are happy with CSS, the DOM, and
scripting then use them; but don?t prevent me from solving my problem.

--- Stephen Deach

--------------end of posting to xml.com-------------------------


----------------------------------------------------------------------------
-------
  Stephen Deach                            |  Sr Computer Scientist
  408-536-6521 (office)                    |  Adobe Systems Inc.
  408-537-4214 (fax)                       |  Mail Stop E15-420
  sdeach@xxxxxxxxx                         |  345 Park Ave
                                           |  San Jose, CA 95110-2704
                                           |  USA
----------------------------------------------------------------------------
-------



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list