CSS vs XSL, what is going on

I haven't seen very much interest directed in particular toward
XML on this list and I think it has been "spared" the discussion
and debate that has been going on about the respective roles of
CSS and XSL.  Pardon me if I am wrong, I have only slightly followed
the list to date.  I think these issues are of some relevance to
the www-style community a therefore I am posting the following
article.  The article has already been posted in xml lists
(xsl-list, xmldev, and comp.text.xml), sorry to anyone that has
seen it already.

ml

---

Mr. Deach, chair of the XSL Working Group, issued a personal response to 
my article in xml.com "XSL Considered Harmful" in the xsl-list mailing list.  
I felt his thoughtful article merited a follow-up from me.

My other responsibilities have prevented me from answering many other
equally compelling articles, for which I beg your understanding.  I
think Mr. Deach has done a good job of bringing most of issues into
sharp focus so I hope these comments will answer the questions of 
many others as to my views.  I am happy to let anyone that wishes to
follow up on this article have the last word as I have had ample
opportunity to let my thoughts be known but if anyone is terribly
keen to pursue any particular point further please cc my email
address at michael@textscience.com.  I am at your service.

The complete text of Mr. Deach's Response is quoted in sections 
in this article.

> 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 appreciate the fact that my colleague, Mr. Deach, chair of the XSL Working
Group, has taken the time to respond to my article and has taken
considerable care in so doing.

Perhaps it is appropriate to state something about my background as well.
I have spent slightly little less time than Mr. Deach in the computer
industry, about 16 years.  One important difference in our experience is
that the greater part of my career was not spent in the area of
document-related tools and products.  Among other things I spent many years 
working on software used in the design of integrated circuits and in magnetic 
resonance imaging.  The last seven years of my career have been dedicated to 
electronic document software, touching on both structured and unstructured 
document technologies.  I worked on a pre-Web SGML browser called Oracle Book,
have been involved in the Web since its earliest days at CERN, and am 
currently working on my second browser, this one based on the mozilla 
open-source code.

The reason I think my non-document related background is important is that
it has always given me a different perspective on technologies like SGML and
XML from that which is common to the vast majority of people working in
this area.  Most of my colleagues have traditionally had publishing-related
backgrounds.  I felt that SGML had the potential to fill a very critical 
niche as an information as opposed to document-related technology but simply 
had too much dross in it originating from the technical view of the publishing 
industry professionals that made the heaviest contribution to the development 
of the standard.  I argued for a "purification" of SGML and at least some of 
my ideas had an influence on the creation of XML.  I am still dissatisfied 
with XML as it still carries some of the dross from SGML but in this imperfect
world it is something I can live with.  I believe that at the core of the 
debate is the difference in view between those that see XML and the web 
primarily as an engine for traditional ideas about document publishing and a 
broader view not tied exclusively to publishing that sees XML as the primary 
interface layer to the multitude of ways in which we can use knowledge, 
computers, and networks.

I should also mention again (it was already stated in the article) something
about my experience with transformation.  It did occur several times in the
debate that noted advocates for XSL made the claim that I or anyone else
that disagreed with their position did not understand XSL.  Along similar
lines some have said that my article was motivated by my economic interests.  I
have not responded to such statements since to the discerning reader they do 
more discredit to the person making them than they could ever do to me.  But 
I do know and understand XSL as well as DSSSL as well as at least a dozen other
approaches to transformation and have made my living as a professional in this
area for several years, choosing the best and most efficient tool for the job
without the least interest in ideological debates.  I may add that I have
received very strong support from my colleagues in this field who are today,
as I was in the past, making their living from doing XML transformation.
And my support for and preference for CSS goes back at least to 1997, long 
before I undertook my current project, as is evidenced by my article "XML 
and CSS", published in the W3C Journal in that year and reproduced in the 
very first issue of xml.com.

Mr. Deach mentions the "timing and stridence" of my article.  While I will
always be extremely quick to apologize for rhetorical excess and any hint of
impoliteness (difficult to avoid from time to time in this medium) I do think 
that the timing is appropriate and the stridence is proportionate with respect
to the overall situation.  I would like to share with you my view of "how the 
war began".

I don't think you will find any stridence at all in my article
"XML and CSS" or my book published last year, "Designing XML Internet
Applications" (where I discuss both XSL and CSS) although I did not hesitate 
to express some doubts about XSL (or DSSSL) and to praise the simplicity and 
power of CSS.  However, the situation begin to look very different in the 
last six to nine months when we saw Microsoft refusing to commit to correct 
support of CSS while introducing XML to the web world in IE5 beta through XSL and 
conversion of XML to HTML on the client.  I begin routinely encountering web 
users who had absolutely no idea that it was even possible to display XML 
without transformation to HTML - using, of course, Microsoft XSL.  To make 
matters worse, what users were encountering was a proprietary implementation 
of XSL far in advance of even the Proposed Recommendation stage which would 
give it status as at least a probable future web standard that
would be reliable in its broader outlines.  In my view experts in the
XML community were doing everything possible to encourage this state of
affairs - there was quite nearly a "blackout" on the mention of alternatives to
transformation and alternatives to formatting such as CSS.  You can not find 
better proof of this than the fact that neither CSS nor the DOM is even 
mentioned as a "standard related to XML" on the SGML/XML on the Web Page.  
As I said to Robin Cover, the editor of the SGML/XML on the Web Page, this is 
a profound disservice to the newcomer to XML who has no indication that the 
simple stylesheet language he may already know from his use of HTML can be 
used to quickly display his XML in a web browser supporting current W3C 
standards.  Instead he is directed to use a declarative transformation 
language which is still a W3C Working Draft to do a document-to-document
transformation to a new presentation-oriented XML language for which no
implementation in browsers currently exists.

I realized what a disastrous situation had emerged, and to large measure
been created by the XML community itself.  The Microsoft browser supports XSL
transformations and the Mozilla browser took the CSS route.  The very 
raison-d'être of the W3C had been shot straight through the heart as it was 
not going to be possible to create one XML web page with one stylesheet and 
to see it correctly displayed in any browser.  And all partisanship aside it 
was obvious who was right and who was wrong: CSS is a W3C Recommendation, XSL 
is not.

I decided that I must speak out on this issue.  I began posting to
comp.text.xml but met mostly incomprehension from people coming over from the 
Microsoft XML list that were convinced that the only proper way to handle XML 
documents was to use Microsoft XSL to convert them to HTML and from the few 
XML folks that deigned to pay attention and only wanted to deflect the 
argument into a pointless debate about whether transformation programs were 
better written in XSL declarative syntax or in a procedural language.  One 
person who finally did respond was Ken Holman after I confronted
him on the stage at the Swedish XML/SGML User's conference with the
statement that XSL advocates bore heavy responsibility for ensuring that we 
did not have a common stylesheet language for XML in browsers.  Ken was 
unable to respond directly to my perfectly accurate assertion but reiterated 
that he thought that transformation was important and that XSL was the way to 
do it.  He later wrote the article that appeared in xml.com where he attempted
to diffuse the "perceived controversy" between XSL and CSS although without 
addressing the major points of the controversy.  My article in
xml.com was originally entitled "A Rebuttal" and was no more than attempt
to present the an "other side" which heretofore had been suppressed by the 
XML community.

But it was not actually when I read Ken's article that the "war" began, it was
a bit earlier when I read Tim Bray and Jon Bosak's article in Scientific
American where it was stated that XSL was "the" stylesheet language for XML.
In demographic terms Scientific American readers are one of the most
influential publication-defined communities on the planet.  It was
then that I said "This is war, it has to be a war."

Finally, Mr. Deach says I make a series of claims which he believes to be
false and goes on to, in his view, refute them.  When I made my
"declaration of war" I did make a strong and open challenge to XSL and thereby
exposed myself and my ideas to, shall we say, extremely intense scrutiny by 
XSL advocates.  Frankly, I am surprised that I did as well as I did, I think 
that an impartial judge would say that each of my major points 
held.  On many points there was essentially no debate whatsoever.
For example:

  A programming or scripting language with the DOM provides a more powerful
  transformation capability than XSL-transformation.
  
  XSL-FO does not provide any clear advantages over CSS formatting and CSS
  is, in fact, a powerful formatting language for XML.
  
  XSL provides no solution to interactivity.
  
These three points alone represent to me an enormous, "captured ground".
The fact is that the whole situation is completely reversed from what it
was before I launched my "war".  The person looking into XML today is not 
going to hear that XSL is "the" stylesheet language for XML.  No one is going 
to claim that CSS, which happens to be the current W3C Recommendation, is not 
a viable alternative to XSL, no XML consultant would dare not to mention CSS.
No one can claim that there are no alternatives to XSL transformations or even
that XSL transformations are indispensable.  No one can ignore the fact
any longer that vendors have not agreed on a single stylesheet standard
for the Web.  The large numbers of people that do not want a declarative
transformation language, do not want to go through a document-to-document
transformation to even see their XML documents, and do not want a
supercharged FONT tag language to replace semantically-rich XML now understand
that there are viable alternatives - that these things are not "the" XML
story.  Those that think XML should be useful in creating a real application
environment in Web browsers are relieved to know that XSL is not
"the" XML story.  I have not enjoyed the "war", I would rather express myself
in very cool code rather than write articles, but I think I have reason to
be proud of these accomplishments.

And on these points alone it is clear that the correct action for W3C members
remains, clearly, to vote against an XSL Recommendation.  As it currently
stands this is very essential because XSL-FO must be dropped.
XSL-FO is entirely redundant with CSS, restricts or eliminates interactivity,
and encourages or even requires the elimination of semantic information from
transformed Web documents.  Even among those who staunchly defended
XSL-transformations there was broad support for this position.  The least 
that should be done is to separate XSL-FO and XSL-transformations into two 
entirely separate initiatives.  I also advocate against approving a separate 
XSL-transformation Recommendation as XSL-transformation does not serve any of 
the purposes for which the W3C creates Recommendations.  Recommendations are 
there for key infrastructure which must be interoperable.  Multiple and 
redundant recommendations work against, not for, interoperability.  A 
document-to-document transformation language like XSL has 
not been shown to be an interoperability requirement and in any case
is redundant with already existing Recommendations.  No one has
successfully argued that the existing Recommendations are inadequate, let 
alone that they could not improved to add new capabilities.

That said, there is no reason why work on XSL-transformation can 
not or should not continue outside of the W3C.  An additional XML tool is
always welcome as long as it does not compromise the interoperable
environment of the Web.

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

If the timing of the challenge is inappropriate it is clear that the timing
of the debate is not.  But the XSL community has accepted my point that
other transformation methods are more powerful than XSL.  No one has suggested
that at a later point in time XSL will be more powerful than can be imagined
or realized today.

> 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.
  
Yes, so I have said myself, and stated that responsible conduct by the
XML community would have been to point new users and vendors at existing
Recommendations.
  
> 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.

Well, ok.  Let's see.

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

I really can't see the connection between "completely false" and the 
explanation of why that might be so.  I think I'll just stick to it, a
transformation technology which does not support interactivity and the
browser environment pretty much has no role to play in a browser.
As I put it, "in the evolution of web technology into the new desktop",
close to an irrefutable statement.

It may not be true that the vast majority of web sites are
essentially static but certainly the vast majority of web pages are.
But evolving web technology doesn't exist to create a web as it exists
today.

I think I provided a pretty good list of real interesting things that can
be done with interactivity "beyond traversal/addressing and some level
of data-entry" in my article.  And I don't think the web community in
general is going to share Mr. Deach blasé feeling about interactivity.

> Claim 2 XSL precludes interactivity.
> Response: No more so than CSS.

Well, does Mr. Deach care about interactivity or not?

It is DOM+CSS that I described as the combination that gives transformation
and interactivity and styling.

> Claim 3 Print has no place on the web.

I said the Web is "not about paper documents" and the web was not the place
to do page composition.  Everyone likes to be able to print documents,
that isn't the issue, it is whether you should expect to get FrameMaker+SGML
documents out of a web browser or not using a page composition engine.

> 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. 
  
For which there are existing technologies, fortunately not inside the browser.

>   Paged composition is not significantly more computationally intensive
than 
>   browser formatting. 
  
Ridiculous.

>   Paged views (fit to the window and/or page) are extremely useful for some 
>   content. 
  
For which ... existing technologies ...

>   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. 
  
Repurposing has nothing to do with whether a page composition engine should
be inside a browser.

>   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.
  
The vast majority of web users don't even want to create stylesheets, let
alone declarative transformation programs like XSL.

FINALLY, as Håkon Lie has pointed out, even if you want to do page composition
in the browser XSL still does not do that for you.  Transformation is far
from enough.

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

What does HTML have to do with using XML and a stylesheet?  FOs are a
font tag language which remove the semantics from otherwise perfectly
fine XML that could be displayed with CSS or transformed with the DOM
and keep all the semantic information.  That simple!

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

Our distinguished colleague and author of a very thoughtful and
cautious paper is furthest thing from a dispenser of "FUD" that I
can possibly think of.

I combed through every single article in the Lie-Prescod FO debate and
I came to conclusion that Mr. Lie's arguments were rock solid which is why
I simply pointed to his paper rather than try to better his statement of
the problem.  There was a major sidetrack on HTML and divs which I found 
not at all relevant in the online discussion.

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

Yes, I like this line of argument very much because I realized the reverse
is even more true and it blows away your entire rationale for having an
FO standard.  Just improve CSS however you like and if someone wants an
FO language they can make elements fo1 to fo653 and map each of them to 
a CSS style.

Fortunately it is going to be really rare than anyone needs to do that
and for the majority of users they will be introduced to simple CSS
stylesheets that encourage them to think stylesheet and semantics rather
than going into the whole business of transformation to another language.

The FOs nearly guarantee word processor-like stylesheet abuse.  Really,
it often seems to me that you want to turn the Web browser into Microsoft
Word!

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

We are back to the Print arguments, please see above.  Nothing new in
this nothing new section!

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

Again, see Print.  Where should page composition be done and with what
tools?  XSL isn't enough.  Let's have the whole story.

On the other hand, simple pagination is a reasonable CSS goal.

> 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 

Two, at least.  Right?  And for the scripting, ECMAscript by reference and
the language-specific binding in the DOM make the third at least debatable.

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

Dealt with adequately and fairly in my paper.  What is false is that XSL makes
anything difficult any easier.  Just about any serious transformation takes
someone with the skills equivalent to some kind of programmer.

Fortunately the vast majority of web documents will be very happy with a CSS
stylesheet.  It is XSL that sets the entry bar unreasonably high.

And not only are we not going to see reasonable transformation tools
for graphic artists but most people would rather you didn't hand them
a language for which they must have such tools before they can do anything.

> Claim 9 XSL didn't take into account anything learned from history (I 
> assume this means CSS)

I don't know where this is from.  My two favorite themes have
been the history of the development of programming languages (declarative
transformation languages have been tried and failed) or the history
of the evolution of the web (stepwise refinement of the existing environment
unless there is a truly compelling leap possible).  The discussion which
follows about XSL and CSS is not a point I have ever gone into.

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

But we have never had a complete implementation of CSS1, let alone CSS2.
I wonder how much we can all really understand so we can build on this
effectively?  We had many years to think about the flaws of SGML before
we created XML.  We had an enormous test bed for each revision of HTML
before the next came along.  We have not gone up the learning curve with
CSS.

I hear claims like "DSSSL is not a sufficient answer to the web formatting 
problem", and a "different architecture [from CSS'] is needed to support
some of the extensibility that XSL requires" without support for the 
assertions.  I don't think either of these assertions are true.  DSSSL does 
arbitrary transformation, period.  What is wrong with DSSSL?  What is meant 
with "different architecture" is usually simply the transformation capability.
Which has been shown can be done in other ways, when and where it is needed.

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

Well, let's see you get 100% beyond a full CSS1 and CSS2 implementations in
browsers, let's see you second my (polite and appreciative) note of protest
to the SGML/XML on the Web page about the omission of CSS as a related XML
standard, let's see you amplify my warning about the fact that we do not have
a single stylesheet standard for XML today and maybe, maybe, I will begin
to lend some credence to your claim here.

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

Stylesheets have been a part of the web for years as well as part of
authoring tools for many more years.  This is a somewhat familiar concept
to the average computer literate person.  It is preposterous to suggest that
document-to-document transformation is as easy as a stylesheet.

I have compared the difficulty of DOM and scripting compared to XSL on
the basis of 
 
   experience with declarative vs. procedural languages
   
   on the fact that programming languages support modular 
   construction and other features to ease the writing of 
   maintainable programs, and that
   
   virtually any programming language will permit
   one to perform a plethora of common and essential tasks 
   that are not supported in XSL.

I haven't seen any refutation of these points.

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

If the goal of all this were just to write a formatter.  So are you willing
to say that as a general transformation engine XSL is not really useful
and that it really is designed only to provide one part of a page composition
engine?

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

The analysis is fine but the question still remains - how narrow is the
solution space?  The professionals from the transformation field are
saying that XSL is too narrow for general transformation.  I don't see
any disagreement with this essential point. 

I think that in addition to joining me supporting CSS you probably should
also be with me on the DOM and transformation as well.  If you are willing to
admit that all XSL can and should do is perform page composition I'll
be only too happy to leave you in peace.

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

Well, I've been getting different feedback.  I don't think we've heard from
the broad web community yet.  The W3C is not a purely industrial consortium
and we have a self-interest as well as human interest in taking into account
the effect of what we do on humankind for whom the Web has become the gateway
to our collective knowledge.  XSL is not a technology which is going to
make participating in the Web easier or better for the majority of users and
it is not to enable critical applications with additions to the infrastructure
which do not exist today.

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

The most amusing thing I read in the whole XSL debate was the article
by a gentleman who attempting to depict me as a grouchy old grandpa
sitting in a rocking chair on his sagging porch, chewing on a pipe and
grumbling "Dag-nabit, all those young whipper-snappers want to go and
change everything, why in my day we didn't have all those darn-tootin
fancy languages, why we wrote computer programs in Assembler and if it
didn't work we just tapped on those darn transistor tubes and everything
worked just fine, those were the days".  Arguing against a technology which
one considers a wrong turn and a serious one at that is not the same as 
being against technology progressing.  Obviously.

> If XSL provides a better mechanism to support online presentation, it is 
> clearly in the web community's interest. 

Not demonstrated.

> If it provides a better solution to 
> print it is clearly in the web community's interest.

First we need to define the problem as such and not a problem of general
transformation or styling.  Once we do that we need to know a little bit
more about the formatting backend.  And than we will decide if it is all
worth it.

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

There is no sense to "common mechanism".  It appears that we have a
good online presentation system, Mr. Deach argues that we need a page
composition system, and there is no argument defending the idea that they
need to be common.

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

You are welcome to solve your problem.  The question whether you should have
a W3C Recommendation to do it with since W3C Recommendations, if they are to
remain meaningful, become an indispensable part of the interoperable Web
infrastructure.

Michael Leventhal

Received on Thursday, 10 June 1999 07:55:43 UTC