Stephen Deach: Response to Leventhal's Article
From sdeach@Adobe.COM Mon May 31 06:59:08 1999 Date: Fri, 28 May 1999 16:44:25 -0700 From: Stephen Deach <sdeach@Adobe.COM> To: xsl-list@mulberrytech.com Subject: My response to Leventhal's article...
[Response to "XSL Considered Harmful," by Michael Leventhal.]
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: Again, 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.
Response: 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:
- 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.
- Paged composition is not significantly more computationally intensive than browser formatting.
- Paged views (fit to the window and/or page) are extremely useful for some content.
- 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.
- 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
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop E15-420
sdeach@adobe.com | 345 Park Ave
| San Jose, CA 95110-2704
| USA
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Prepared by Robin Cover for the The SGML/XML Web Page archive.
