XSL Debate, Leventhal responds to Stephen Deach

[Michael Leventhal]

The following article was posted on the xsl-list and the newsgroup
comp.text.xml.  My apologies to those that read more than one of
these lists.  Although most of you are probably tired on the XSL
debate by now I felt this would interest some on this list.

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 at 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 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
"standards 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 in
that an
impartial judge would say that each of my major points essentially 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 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 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 fast 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.

> 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 scripting
tools
that 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 is 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

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)